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CHAPTER  I 

GENERAL  DESCRIPTION 


This  document  is  a  user's  guide  to  the  LOGATAK  simulation  model  and 
the  DAMSEL  data  base  program.  The  first  chapter  provides  a  general  des¬ 
cription  of  the  programs  and  their  uses.  The  second  chaDter  describes  now 
a  user  specifies  a  particular  scenario  which  will  be  used  in  the  rr  ^il 
analysis.  Chapter  III  describes  the  DAMSEL  data  management  and  selection 
program  in  detail.  Chapter  IV  describes  the  input  data  for  the  LOGATAK 
model,  including  deck  structures  and  card  formats.  The  reports  produced  by 
the  LOGATAK  model  are  described  and  examples  are  shown  in  Chapter  V.  The 
operating  strategy  for  running  the  model  and  analyzing  the  results  is 
discussed  in  Chapter  VI.  Chapter  VII  treats  expanded  force  movement  and 
interdiction  options. 

1.  PURPOSE  AND  USE 

1.1  LOGATAK 

The  LOGATAK  simulation  model  was  developed  to  assess  the  impact 
of  interdiction  on  a  logistic  network  and  to  aid  in  developing  attack 
strategies  on  the  network.  The  model  represents  a  multi-echelon  supply 
system  connected  by  a  multi -mode  transportation  network.  The  movement  of 
shipments  throughout  the  network  is  simulated  over  time  to  permit  the 
analysis  of  traffic  flows  and  overloads.  The  model  utilizes  the  available 
transportation  capability  to  move  all  shipments  and  chooses  alternate 
routes  if  overloads  or  attacks  reduce  the  capability. 

The  model  was  designed  to  handle  a  wide  range  of  scenarios  and 
transportation  networks.  The  user  can  select  any  geographic  area  that  is 
covered  by  the  data  base  and  specify  the  location  of  supply  bases  and  the 
movement  of  units  over  the  area  selected.  Varying  demand  patterns  may  be 
specified  to  represent  changing  conditions  on  the  battlefield.  The  demands 
from  units  in  different  locations  drive  the  model  to  satisfy  the  movement 
requirements  over  the  transportation  network. 
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^he  norma!  mode  of  operation  for  the  LOGATAK  model  's  a  oaseline 
run  during  wnich  no  interdiction  is  performed,  followed  by  a  series  of  runs 
to  test  various  attack  strategies.  A  comparative  analysis  can  then  be  per¬ 
formed  on  the  system  response  under  varying  conditions.  The  model  also 
includes  a  target  allocation  algorithm  (TARGAA)  which  aids  in  determining 
preferred  attack  strategies. 

1.2  DAMSEL 

Program  DAMSEL  was  developed  as  an  effective  means  of  aata  man¬ 
agement  and  data  selection.  It  serves  as  an  interface  between  the  logis¬ 
tical  data  base  and  the  LOGATAK  simulation  model.  It  performs  this 
function  in  both  directions,  i.e.,  taking  data  from  the  data  library  and 
converting  to  the  proper  formats  for  LOGATAK,  and  by  providing  convenient 
printed  output  enabling  the  analyst  to  reference  the  LOGATAK  results  back 
to  the  logistical  data  base. 

In  its  role  as  data  manager,  program  DAMSEL  performs  four  basic 
tasks:  (1)  adds,  (2)  deletes,  (3)  updates  and  (4)  orders.  The  program  can 
add  new  data  to  or  delete  data  from  the  library.  DAMSEL  also  has  the 
capability  of  updating  one  or  more  variables  of  a  particular  data  entry  in 
the  library.  These  three  tasks  are  all  carried  out  while  keeping  the  data 
ordered  according  to  a  specified  arrangement.  The  ordering  of  the  data  in 
the  library  enables  DAMSEL  to  operate  more  efficiently  in  selecting  sec¬ 
tions  of  data  for  analysis. 

The  other  main  function  of  DAMSEL  is  to  select  data  from  the  data 
library  as  requested  by  the  analyst.  Because  the  data  library  can  be  quite 
extensive,  and  because  computer  core  restrictions  limit  the  amount  of  data 
which  can  fit  into  the  machine  with  LOGATAK,  it  becomes  necessary  to  select 
only  the  data  which  is  pertinent  to  the  analysis  being  performed.  Once  the 
appropriate  data  has  been  selected  from  the  data  library  it  is  transformed 
into  the  proper  format  for  LOGATAK.  This  data,  ready  for  use  by  LOGATAK, 
is  stored  on  a  permanent  file.  The  printed  output  of  DAMSEL  provides  a 
cross-reference  between  the  logistic  data  base  entries  and  their 
corresponding  LOGATAK  format. 


2.  GENERAL  CHARACTERISTICS 

2. 1  LOGATAK 

The  LOGATAK  model  is  a  discrete-event,  stocnastic  simulation 
model  consisting  of  supply  demand  generator  nodes,  intermediate  stocKage 
points,  supply  source  nodes,  and  a  multi-mode  transportation  networK 
connecting  these  nodes.  The  flow  of  shipments  in  response  to  demands  from 
the  supply  nodes  is  simulated  over  time  on  the  transportation  networK.- 
Overload  of  the  transportation  network  causes  queue  buildups  and  rerouting 
of  shipments.  Losses  and  impairments  in  the  network  due  to  attack  at  any 
time  create  similar  effects,  thus  hampering  the  transportation  system's 
ability  to  respond  to  the  demands.  The  basic  measures  of  effectiveness  in 
the  model  are:  the  percent  of  materiel  demanded  which  is  received,  the 
response  time  experienced,  the  intermediate  inventory  levels,  and  the 
resource  utilization  and  workloads  in  the  transportation  network. 

Figure  1-1  shows  the  basic  inputs  and  outputs  for  the  model.  The 
user  defines  the  transportation  network  (with  the  help  of  DAMSEL),  the 
scenario,  and  the  initial  stockage  levels.  The  model  is  then  run  and 
transportation  workloads  and  demand  satisfaction  are  reported.  Optional 
attacks  can  be  specified  by  the  user  or  by  TARGAA  to  disrupt  the  network 
and  effect  the  outcome.  A  general  description  of  LOGATAK  inputs  and  out¬ 
puts  is  given  in  Table  1-1.  A  complete  specification  is  provided  in 
Chapters  IV  and  V. 

The  model  is  a  sophisticated  simulation  model  with  complex  logic 
to  handle  the  many  decisions  arising  from  traffic  routing  and  overload 
rerouting.  The  model  enables  the  user  to  study  the  interactions  between 
many  shipments  in  a  multi -mode  transportation  network  under  a  wide  range  of 
conditions.  In  addition,  conditions  in  the  network  can  be  altered  during 
the  model  run  by  such  outside  forces  as  attacks  and  weather.  The  model 
then  adjusts  to  the  new  conditions  and  the  traffic  flow  during  the  transi¬ 
tion  period  can  be  studied. 

The  model  program  is  written  in  the  FORTRAN  language  and  is 
currently  operational  on  a  Control  Data  Corporation  CYBER  73  computer 
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Figure  1-1.  LOGATAK  Simulation  Model 
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TABLE  1-1.  LOGATAK  MODEL 


INPUTS 

OUTPUTS 

•  NETWORK  DESCRIPTION 

•  SUPPLY  STATUS  BY  NODE/CLASS 

LINK  ANO  TERMINAL  SPECS 

QUANTITY  ORDERED 

MODE 

QUANTITY  RECEIVED 

LENGTH 

QUANTITY  DUE- IN 

RATE  OF  TRAVEL 

DURATION  OF  DUE- INS 

CAPACITY 

•  TRANSPORTATION  STATUS 

TIME  TO  REBUILD 

NETWORK  CHARACTERISTICS 

•  SCENARIO 

NETWORK  WORKLOADS 

TIME  PHASED  DEMANDS 

FOR  EACH  LINK/TERMINAL 

LOCATION  OF  DIVISIONS 

AVERAGE  LOAD 

PRIORITY  OF  DIVISIONS 

PEAK  LOAD 

•  INITIAL  STOCKAGE  AT  SUPPLY 

TOTAL  THRUPUT 

POINTS 

QUEUE  BUILDUPS 

•  ATTACKS 

•  ATTACK  RESULTS 

WHERE 

WHEN 

13 


A 


system  (equivalent  to  the  large  CDC  6000  series  computers).  The  program  is 
a  dynamic  simulation  model  that  can  handle  data  changes  during  execution. 
The  model  has  a  restart  capability  so  that  a  run  may  be  stopped  at  any  time 
and  restarted  from  that  point  in  simulation  time  after  analysis  of  the 
output.  The  model  also  has  event  trace  and  transaction  file  capabilities. 
The  trace  allows  the  user  to  verify  that  the  logical  decisions  are  being 
maae  properly  within  the  model.  The  transaction  file  permits  post-model 
run  analysts  and  grapning  of  the  results. 

2.2  DAMSEL 

Program  DAMSEL  was  developed  in  order  to  provide  a  smooth  trans¬ 
ition  between  the  data  base  and  the  LOGATAK  simulation.  It  was  first 
considered  only  as  a  tool  to  ease  in  formatting  the  data  for  use  in 
LOGATAK;  however,  its  greatest  task  became  that  of  managing  the  data  base 
itself.  Because  of  the  size  of  the  data  base  and  the  limitations  of  core 
requirements  from  LOGATAK,  only  portions  of  the  data  base  could  be  utilized 
at  any  one  time.  Therefore  it  was  necessary  to  have  a  means  of  "selecting" 
segments  of  data  from  the  full  data  base  to  provide  input  for  a  LOGATAK 
investigation.  DAMSEL  was  developed  as  a  preprocessor  program  for  the 
logistics  data  base. 

It  was  determined  early  on  that  some  trade  offs  were  necessary 
between  data  base  and  LOGATAK  because  of  computer  size  and  core 
restrictions.  The  result  of  one  trade  off  was  the  sectoring  of  data. 
Because  of  this  trade  a  preprocessing  program  was  needed  to  convert  data 
from  its  map/sector  form  to  the  proper  LOGATAK  format  and  numbering 
sequence. 

DAMSEL  is  written  in  FORTRAN  IV  in  modular  form.  The  subroutines 
represent  the  major  operations  of  the  simulation,  namely,  data  management 
and  data  selection.  The  main  (or  executive)  program  acts  as  controller 
setting  the  proper  conditions  and  calling  the  appropriate  operations. 

The  heart  of  the  program  is  the  data  base  library  and  manipula¬ 
tions  of  same.  To  ease  the  data  selection  process  discussed  previously  the 
data  library  is  ordered  with  respect  to  coded  data  identification  numbers. 
This  order  must  be  maintained  whenever  a  new  data  library  is  created.  To 
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accomplish  this,  changes  to  the  data  base  must  be  presorted  and  submitted 
in  proper  order.  This  presort  requirement  eases  programming  operations  ana 
eliminates  the  need  for  numerous  passes  through  the  data  library  file. 

The  program  requires  as  many  as  eight  input/output  files 
depending  upon  what  functions  are  being  performed.  Two  files  are  utilized 
for  the  data  library.  Four  files  are  needed  for  the  select  function 
including  two  working  files  and  two  output  files  to  feed  LQGATAK.  The 
remaining  files  are  the  basic  input  and  output  to  the  program. 

The  entire  DAMSEL  program  consists  of  approximately  600  state¬ 
ments.  Its  compilation  time  is  less  than  ten  seconds  on  a  CDC  6000  Series 
Computer  utilizing  18,000  words  of  core. 

3.  ACTIVITIES  SIMULATED 

3. 1  Supply  Structure 

The  supply  users  in  the  model  are  simulated  as  nodes  representing 
military  units  or  aggregations  of  units  which  generate  demands  for  various 
classes  of  supply  over  time  (based  on  the  scenario  being  modeled).  Inter¬ 
mediate  stockage  points  in  the  model  receive  demands  from  the  user  nodes 
and  either  fill  the  demands  from  inventory  or  pass  the  demands  to  a  higher 
echelon.  These  stockage  points  maintain  inventory  levels  by  ordering 
replenishments  from  a  higher  echelon.  The  source  of  materiel  in  the  model 
is  represented  by  nodes  that  fill  all  demands  from  the  lower  echelon  supply 
nodes.  Fill  delays  may  be  represented  at  these  nodes  to  indicate  back¬ 
orders  and  stock  availability  problems. 

One  or  more  supply  classes  may  be  represented  at  each  supply  node 
in  the  model.  There  is  no  fixed  maximum  on  the  number  of  classes  of 
materiel  other  than  computer  core  storage  limitations.  Example  supply 
classes  are  ammunition,  packaged  POL,  and  bulk  POL. 

The  geographic  locations  of  supply  nodes  may  change  over  time 
during  the  model  run.  Special  classes  of  materiel  may  be  defined  to 
represent  movement  over  the  transportation  network  of  unit  equipment  and 
personnel . 
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3. 2  Transportation  Network 

The  transportation  function  in  LQGATAK  is  simulated  by  following 
the  movement  of  discrete  shipments  over  time  on  a  terminal-1  ink  networK. 
Up  to  six  modes  of  travel  can  be  included  in  a  network  including  air,  sea, 
rail,  road,  pipeline,  and  transshipment  between  modes.  Shipments  are 
routed  through  the  network  from  source  to  user  terminals  based  on  the 
current  status  of  the  network,  the  priority  and  the  size  of  the  shipment. 
The  loading  on  the  terminals  and  links  is  measured  and  delays  associated 
with  travel  time,  terminal  operations,  and  queueing  are  used  to  determine 
delivery  time. 

The  terminals  and  links  of  the  transportation  network  are 
assigned  vulnerabi 1 ity  factors  and  rebuild  times.  Any  element  of  the 
network  may  be  attacked  at  any  time  during  the  model  run.  The  model  cal¬ 
culates  the  reduction  in  capacity  and  the  time  it  will  take  to  rebuild  the 
element.  Shipments  are  rerouted,  utilizing  the  remaining  capacity  in  a 
network  after  an  attack. 

4.  COMPUTER  SYSTEM  REQUIREMENTS 

The  LOGATAK  model  program  is  written  in  the  FORTRAN  language  and  is 
currently  operating  on  a  Control  Data  Corporation  6000  series  computer. 
The  program  is  designed  on  the  modular  principle  and  contains  over 
350  subprograms.  The  current  configuration  of  the  model  requires 
92,600  words  of  core  storage  to  execute.  This  configuration  can  handle  up 
to  20  demand  generators,  5  intermediate  stockage  points,  5  supply  sources, 
300  terminals,  and  600  links.  It  also  includes  the  program  TARGAA  in  the 
same  core  overlay  with  the  model. 

The  running  time  for  the  model  varies  depending  on  the  scenario,  the 
transportation  network,  and  the  activity  being  represented.  An  estimated 
range  for  a  large  application  is  10  to  20  minutes  of  central  processor  time 
for  a  CDC  CYBER  73. 
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CHAPTER  II 
SCENARIO  DESIGN 


1.  INTRODUCTION  AND  PURPOSE 

This  chapter  describes  a  numDer  of  factors  whicn  must  be  con¬ 
sidered  in  the  design  of  a  scenario  for  use  in  the  LOGATAK  model.  This 
scenario  must  serve  a  numuer  of  different  purposes:  it  must  describe  the 
general  operating  plan  of  the  military  units  and  their  supporting  logistics 
system  which  is  to  be  subjected  to  interdiction;  it  must  convert  that 
operational  plan  into  specific  detailed  movements  of  the  military 
units;  it  must  identify  and  describe  the  classes  of  supplies  which  flow 
through  the  logistics  system;  and,  it  must  describe  the  supply  bases  which 
process  these  supplies.  In  considering  all  of  these  factors  in  detail,  it 
must  be  remembered  that  computer  core  is  limited,  and  only  data  which  is  of 
significance  to  the  results  of  the  model  exercise  should  be  contained  in 
the  scenario.  The  scenario  design  must  seek  a  middle  ground  between  two 
extremes.  On  the  one  hand,  it  cannot  be  so  detailed  that  the  computer  bogs 
down  with  superfluous  information  and  cannot  complete  the  desired  model 
run,  while  on  the  other  hand,  the  scenario  must  not  be  so  aggregated  that 
factors  important  to  the  answer  are  omitted  and  the  final  results  thereby 
preordained.  A  more  detailed  discussion  of  the  trade-offs  involved  in 
making  this  balance  is  contained  in  Chapter  VI,  Operating  Strategy. 
Another  important  point  which  should  be  kept  in  mind  during  the  scenario 
design  is  the  necessity  of  using  data  formats  that  are  compatible  with  the 
LOGATAK  program.  These  formats  are  described  in  detail  in  Chapter  III, 
DAMSEL  (Data  Management  and  Selection  System),  and  Chapter  IV,  LOGATAK 
Inputs. 
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2.  OPERATIONAL  PLAN 


/ 


2. 1  Objectives  of  the  Force  Subjected  to  Interdict! ve  Attack 

The  first  step  in  preparing  an  operational  plan  is  to  clearly 
define  and  outline  the  objectives  desired  by  the  side  subjected  to  inter- 
dictive  attack.  These  objectives  include  whether  the  operation  is  offen¬ 
sive,  defensive,  or  a  combination,  the  tactics  (in  general  terms)  used  to 
achieve  these  objectives,  the  desired  rate  of  movement  of  the  forward  edge 
of  the  battle  area  (FEBA),  and  the  geographic  objectives  of  the  operation. 

2.2  Detailed  Operational  Plan 

The  overall  objectives  of  the  force  subjected  to  interdiction 
must  be  expanded  into  a  detailed  operational  plan  which  describes  the  units 
contained  within  this  force,  and  the  operations  which  these  units  conduct 
against  their  enemy,  as  a  function  of  time  during  the  scenario.  For  exam¬ 
ple,  which  of  the  units  are  to  be  in  the  front  line  and  which  in  reserve, 
what  types  of  tactics  will  the  units  use,  and  at  what  times  will  special 
reserves  be  employed?  Since  different  military  forces  generally  have 
different  doctrines  with  respect  to  these  matters,  it  is  important  to 
research  the  operational  doctrines  of  the  military  force  being  described, 
in  order  to  maintain  a  desirable  degree  of  realism. 

2.3  Geographic  Locale  of  Operation 

In  describing  the  overall  operational  plan,  the  locality  in  which 
the  operation  is  to  take  place  must  be  defined,  and  the  geographic  details 
of  this  location  must  be  examined  in  the  context  of  the  tactical  opera¬ 
tions.  The  presence  of  geographical  features  such  as  rivers,  mountain 
ranges,  etc.  are  significant  not  only  to  the  operation  of  the  logistics 
system  to  be  interdicted,  but  also  to  the  tactical  movements  of  the  mili¬ 
tary  units  being  supported  by  that  logistics  system.  The  detailed  opera¬ 
tional  plan  must  reflect  the  presence  of  geographical  features  by  taking 
advantage  of  these  features  in  both  attack  and  defense,  as  a  field  com¬ 
mand  er  would  do. 
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3.  MILITARY  UNITS 


3. 1  Designations 

The  military  unit  organization  of  the  force  to  be  interdicted 
must  be  defined  in  order  to  generate  the  desired  set  of  logistic  demand 
generators.  It  may  be  necessary,  if  computer  facilities  are  not  secure,  to 
develop  a  set  of  coded  designations  of  the  units  involved  to  maintain 
security.  By  either  actual  or  coded  designation,  however,  every  demand 
generator  involved  in  the  scenario  must  be  individually  identified  by  a 

designation  compatible  with  the  LOGATAK  model  input  format. 

3.2  Initial  Stockage 

The  initial  stockage  of  each  designated  demand  generator  and 

supply  base,  in  each  type  of  supply  to  be  used  in  the  model,  must  be 
defined.  The  initial  stockage  is  the  level  of  supply  available  at  the 

beginning  of  the  scenario  run,  and  reflects  the  "cushion"  available  to  the 

unit  or  base  against  running  out  of  supplies  before  the  logistics  system 
can  replace  consumption. 

3.3.  Types  of  Activity 

For  every  unit  of  time  in  the  scenario,  e.g. ,  day,  the  type  of 
activity  of  each  demand  generator  must  be  defined.  Most  major  countries 
have  published  reports  which  define  the  consumption  rates  of  various 
classes  of  supplies  for  various  types  of  activity,  such  as  attack  against 
defended  positions,  meeting  engagements,  hasty  defense,  etc.  The  types  of 
activity  defined  for  each  demand  generator  should  correspond  as  much  as 
possible  with  the  doctrine  definitions  of  activity  in  order  to  facilitate 
the  determination  of  consumption  rates.  The  types  of  activity  for  each 
demand  generator  can  generally  be  selected  from  a  review  of  the  detailed 
operational  plan.  In  the  interest  of  reality,  if  an  unusual  type  of  activ¬ 
ity  is  contemplated  which  does  not  correspond  to  any  predefined  doctrine,  a 
new  designation  of  activity  should  be  adopted. 


3. 4  Supply  Consumption  Rates 

The  consumption  rates  for  eacn  class  of  supplies  and  the  fre¬ 
quency  of  orders  of  these  supplies  must  be  defined  for  each  demand  gene¬ 
rator  in  the  scenario.  As  previously  indicated,  standard  military  logistic 
doctrine  texts  are  very  helpful  in  determining  consumption  rates  for  typi¬ 
cal  units  engaged  in  standard  types  of  activity.  If  the  analyst  believes 
that  the  scenario  under  consideration  does  not  correspond  to  a  standard 
classification,  however,  he  should  use  consumption  rates  and  frequency  of 
orders  which  he  feels  are  realistic  in  the  particular  case.  The  consump¬ 
tion  rates  and  frequency  of  orders  must  be  defined  in  a  format  compatible 
with  the  LOGATAK  model  input  requi rements. 

3. 5  Unit  Locations 

The  location  of  each  military  unit  (demand  generator)  must  be 
identified  each  time  that  the  unit  moves,  and  the  length  of  time  at  each 
location  must  be  defined.  A  location  of  a  military  unit  is  generally  out 
in  the  field,  not  coincident  with  any  fixed  node  in  the  transportation 
network  of  the  area.  The  fixed  node  through  which  supplies  will  be  sent  to 
the  unit  field  location  must  be  identified,  and  the  temporary  transporta¬ 
tion  link  between  the  military  unit  location  and  the  fixed  node  must  be 
described.  This  description  should  include  length,  capacity,  and  rate  of 
travel.  It  is  necessary  to  define  all  successive  locations  of  a  given  unit 
for  the  duration  of  the  scenario  so  the  simulation  model  can  forward  sup¬ 
plies  to  the  new  unit  location  if  the  unit  moves  while  its  supplies  are  in 
transit  in  the  logistics  system.  Figure  I I- 1  shows  a  sample  network  with 
successive  locations  for  three  tank  units  in  the  field  tied  into  the  exist¬ 
ing  transportation  network. 

3. 6  Unit  Moves 

Depending  on  whether  a  particular  unit  is  located  in  the  forward 
battle  area  or  in  the  rear  area  of  the  logistic  network,  the  movement  of  a 
unit  from  one  location  to  another  may  create  a  significant  additional  load 
upon  a  logistic  network.  The  movements  of  military  units  which  compete  for 
use  of  the  available  capacity  of  a  transportation  link  with  the  movements 
of  supplies  must  be  carefully  accounted  for,  as  military  unit  moves  can 
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Figure  1 1 - 1 .  LOGATAK  Network 


easily  become  the  most  serious  load  on  the  logistics  net.  Sucn  unit  moves 
snould  receive  attention  during  the  scenario  design  to  maxe  sure  that 
reality  is  preserved  and  artificial  oottlenecks  are  not  created  in  the 
system. 

4.  SUPPLIES 

4.  I  Classes  of  Supply 

The  LOGATAK  model  will  accommodate  a  large  number  of  classes  of 
supply  within  the  existing  model  structure.  Typical  classes  of  supply  are 
ammunition  of  various  types  and  POL.  Although  the  capability  for  handling 
many  types  of  supplies  is  present,  the  analyst  should  remember  that  each 
additional  class  of  supply  accounted  for  in  the  model  consumes  an  addi¬ 
tional  amount  of  computer  core  capacity  and  thus  reduces  the  anility  to 
consider  other  aspects  of  the  problem.  The  classes  of  supply  used  in  the 
model  exercise  should  be  restricted  to  those  which  have  a  significant 
effect  on  the  total  load  in  the  logistics  system,  and  classes  of  supply 
consisting  of  only  a  minor  fraction  of  the  total  can  usually  be  disregarded 
without  affecting  the  final  answer  significantly. 

4. 2  Priorities 

The  LOGATAK  model  will  accept  the  designation  of  different  levels 
of  delivery  priority  for  different  classes  of  supply  and  of  users.  The 
assignment  of  priority  should  be  made  after  careful  consideration  of  the 
operational  plan,  and  the  effect  on  the  combat  units  of  a  shortage  of  each 
class  of  supply. 

4. 3  Quantitative  Description  of  Classes  of  Supply 

Each  class  of  supply  must  be  defined  according  to  the  weight  and 
cubage  associated  with  a  unit  amount.  For  supplies  such  as  ammunition  and 
POL,  these  numbers  may  be  obtained  from  standard  references. 


SUPPLY  BASES 


5. 1  Designation  of  Supply  Bases 

As  .n  the  case  of  military  units,  the  selection  of  suopiy  oases 
must  be  based  on  the  oest  available  information  concerning  the  types  of 
supplies  to  be  handled  and  the  logistic  doctrines  of  the  particular  force 
involved.  If  computer  security  is  a  problem,  supply  bases  may  be  given 
coded  designations  in  the  same  manner  as  military  units. 

5. 2  Initial  Stockaqes 

In  the  same  manner  as  military  units,  the  initial  stockage  of 
each  class  of  supply  available  at  each  supply  base  must  be  defined.  The 
levels  of  initial  stockage  for  each  level  of  supply  should  be  consistent 
with  the  logistic  doctrine  with  the  force  involved,  as  well  as  the  degree 
of  advance  preparation  assumed  before  the  scenario  begins. 

5.  3  Forwarding  of  Supply  Demand  Orders 

The  LOGATAK  model  permits  the  forwarding  of  supply  demand  orders 
from  a  supply  base  to  another  base  at  a  higher  echelon,  if  the  f-r-t  bass 
to  receive  the  order  is  unable  to  fill  it.  Each  intermediate  supply  base 
in  the  scenario  must  be  associated  with  the  designation  of  its  next  higher 
echelon  supply  base,  to  which  the  unfilled  orders  are  referred. 

5.4  Movements  and  Locations 

In  the  same  manner  as  military  units,  the  location  of  each  inter¬ 
mediate  and  source  supply  base  must  be  identified  for  each  time  interval  of 
the  scenario.  If  the  supply  base  moves  during  the  scenario,  the  time  of 
the  move  must  be  identified.  Supply  bases  are  usually  located  closer  to 
the  nodes  in  the  fixed  transportation  network  than  are  military  units,  but 
they  may  still  be  located  a  short  distance  from  the  nearest  transportation 
terminal  node,  and  the  length,  capacity  and  average  rate  of  speed  of  the 
connecting  link  to  the  terminal  node  must  be  specified.  Supply  bases  are 
frequently  tied  simultaneously  to  more  than  one  type  of  transportation 
terminal,  for  example,  highway  and  rail.  If  a  supply  base  is  tied  to  more 
than  one  mode  of  transportation,  the  links  connecting  the  supply  base  to 


each  type  of  terminal  node  must  be  independently  specified.  Figure  II- 
shows  supply  bases  located  in  a  transportation  network. 
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CHAPTER  III 

OAMSEL:  INPUTS  AND  OUTPUTS 

1.  INPUTS 

1 . 1  Peck  Structure 

Inputs  to  program  OAMSEL  are  concerned  with  its  two  basic  func¬ 
tions;  (I)  altering  the  data  base  library,  and  (2)  selecting  data  from  the 
library  for  analysis.  The  first  function  is  further  divided  into  two 
tasks;  (1)  alterations  to  link  data  and  (2)  alterations  to  terminal  data. 
These  two  tasks  together  with  data  selection  comprise  the  major  blocks  of 
input  to  program  OAMSEL.  Any  individual  input  block  or  combination  of 
blocks  may  be  used  for  a  single  DAMSEL  run.  However  input  blocks  must  be 
in  the  order  shown  in  Figure  III-l  and  each  block  may  be  used  only  one  per 
run.  If  a  particular  input  block  is  not  being  utilized  it  is  not  included 
in  the  input  data  deck. 

1 . 2  Link  Alterations 

The  first  data  block  to  appear,  if  needed,  is  link  alterations. 
The  formats  for  these  cards  are  shown  in  Table  III-l.  The  number  of  link 
cards  is  not  constrained,  however  they  must  be  ordered  according  to  their 
first  terminal  number  with  the  smallest  number  first.  Links  which  are 
defined  by  the  same  first  terminal  number  are  grouped  together  with  no 
further  ordering  being  necessary. 

There  are  three  link  alterations  which  can  be  performed  by  DAMSEL 
and  are  indicated  in  card  column  five. 

CC5  DAMSEL  OPERATION 

BLANK  ADD  LINK  DATA  TO  LIBRARY 

0  DELETE  LINK  DATA  FROM  LIBRARY 

C  CHANGE  ONE  OR  MORE  VARIABLES  OF 

DEFINED  LINK  IN  LIBARY 
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TABLE  III- 1 .  LINK  DATA  CARO  FORMATS 


FIRST  CARD 

CC  1  - 

CC  5 

A5 

ENTER  CHG  (LEFT  JUSTIFIED) 

CC  6  - 

CCIO 

A5 

ENTER  LINK  (LEFT  JUSTIFIED) 

cell  - 

CC80 

70X 

BLANK 

LINK  DEFINING  CARDS 

CC  1  - 

CC  4 

A4 

CARD  NAME  -  LINK 

CC  5 

A1 

PROGRAM  INSTRUCTION 

(C,  0,  OR  BLANK) 

CC  6  - 

CCIO 

A5 

LINK  TYPE  (RAIL,  HWY ,  TRANS,  AIR) 

CC11  - 

CC20 

no 

TERMINAL  NUMBER 

CC21  - 

CC30 

no 

TERMINAL  NUMBER 

CC31  - 

CC35 

15 

ROUTE  NUMBER 

CC36  - 

CC45 

FIO. 3 

LINK  LENGTH 

CC46  - 

CC55 

Flo. 3 

CAPACITY  OF  LINK 

CC56  - 

CC60 

F5.0 

VULNERABILITY  FACTOR 

CC61  - 

CC65 

F5.0 

TIME  TO  REBUILD 

CC66  - 

CC70 

F5.0 

RATE  OF  TRAVEL 

CC71  - 

CC77 

7X 

BLANK 

CC78  - 

CC80 

A3 

RIVER  CODE 

LAST  CARD 

CC  1  - 

CC  5 

A5 

ENTER  LINK  (LEFT  JUSTIFIED) 

CC  6  - 

CCIO 

A5 

ENTER  END  (LEFT  JUSTIFIED) 

ecu  - 

CC80 

70X 

BLANK 

7 
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The  last  operation  requires  two  link  cards.  The  first  card  must  define  the 
link  exactly  as  it  appears  in  the  present  data  base.  The  following  card 
provides  the  new  values  for  the  variables  to  be  changed.  Only  the  vari¬ 
ables  in  CC21-CC80  may  be  changed.  A  value  of  -1,  -1.,  or  blank  as  appro¬ 
priate  for  integer,  real,  or  alpha  format  can  be  used  to  indicate  no  change 
of  this  variable. 

1 . 3  Terminal  Alterations 

This  is  the  second  block  of  input  data  unless  there  are  no  link 
alterations  being  made  in  which  case  this  block  is  first.  The  formats  for 
this  block  are  presented  in  Table  III-2.  Here  also  the  number  of  terminal 
cards  is  unconstrained.  The  terminal  cards  must  be  ordered  by  terminal 
number  beginning  with  the  smallest  number. 

Similarly  to  the  link  data,  card  column  five  indicates  the  opera¬ 
tion  to  be  performed. 

CC5  DAMSEL  OPERATION 

BLANK  ADD  TERMINAL  DATA  TO  LIBRARY 

D  DELETE  TERMINAL  DATA  FROM  LIBRARY 

C  CHANGE  ONE  OR  MORE  VARIABLES  OF 

DEFINED  TERMINAL  IN  LIBARY 

Unlike  link  data  only  one  card  is  needed  to  change  the  variables  for  a 
terminal.  In  addition  all  variables  must  be  specified  including  those  that 
are  not  changed. 

1.4  Data  Selection 

The  data  selection  block  of  input  is  last  allowing  the  data 
library  to  be  altered  before  data  is  selected.  The  formats  for  these  data 
cards  are  given  in  Table  1 1 1 - 3 .  The  sector  data  cards  identify  the  sets  of 
data  to  be  selected  from  the  data  library.  Each  data  set  is  defined  by  a 
five  digit  number.  The  first  four  digits  uniquely  define  a  sector  and  the 
units  digit  defines  the  mode  of  operation  of  data  desired.  All  modes  for  a 


TABLE  III-2.  TERMINAL  DATA  CARD  FORMATS 


FIRST  CARD 

CC  1  - 

CC  5 

A5 

ENTER  CHG  (LEFT  JUSTIFIED) 

CC  6  - 

CCIO 

A5 

ENTER  TERM  (LEFT  JUSTIFIED) 

CC11  - 

CC80 

70X 

BLANK 

TERMINAL  DEFINING  CARDS 

CC  1  - 

CC  4 

A4 

CARD  NAME  -  TERM 

CC  5 

A1 

PROGRAM  INSTRUCTION 

(C,  D,  OR  BLANK) 

CC  6  - 

CCIO 

A5 

TYPE  OF  TERMINAL  (RAIL,  HWY ,  AIR) 

CC11  - 

CC30 

A20 

TERMINAL  NUMBER 

CC31  - 

CC40 

no 

CODED  TERMINAL  NUMBER 

CC41  - 

CC50 

F10.3 

TERMINAL  CAPACITY 

CC51  - 

CC55 

F5.0 

VULNERABILITY  FACTOR 

•  CC56  - 

CC60 

F5.0 

TIME  TO  REBUILD 

CC61  - 

CC63 

13 

INDEX  OF  CONSOLIDATION  DELAY 

CC64  - 

CC66 

13 

INDEX  OF  LOADING  DELAY 

CC67  - 

CC69 

13 

INDEX  OF  THROUGHPUT  DELAY 

CC70  - 

CC72 

13 

INDEX  OF  UNLOADING  DELAY 

CC73  - 

CC80 

8X 

BLANK 

LAST  CARD 

CC  1  - 

CC  5 

A5 

ENTER  TERM  (LEFT  JUSTIFIED) 

CC  6  - 

CCIO 

A5 

ENTER  END  (LEFT  JUSTIFIED) 

ecu  - 

CC80 

70X 

BLANK 
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TA8LE  III-3.  SELECTION  DATA  CARO  FORMATS 


FIRST  CARD 

CC  1  -  CC  5 

CC  7  -  CC80 

A6 

74X 

ENTER  SELECT 

BLANK 

STATISTICAL  INDICES  CARD 

1 

CC  1  -  CC  2 

12 

AVERAGE  WEIGHT  OF  SHIPMENTS  ON 

CC  3  -  CC  4 

12 

LINK  (3) 

TOTAL  WEIGHT  OF  SHIPMENTS  OVER 

CC  5  -  CC  6 

12 

LINK  (1) 

AVERAGE  CAPACITY  OF  LINK  (3) 

CC  7  -  CC  8 

12 

AVERAGE  WEIGHT  OF  SHIPMENTS  IN 

CC  9  -  CC10 

12 

TERMINAL  (3) 

TOTAL  WEIGHT  OF  SHIPMENTS 

ccn  -  cci2 

12 

PASSING  THROUGH  TERMINAL  (1) 

TOTAL  WEIGHT  OF  SHIPMENTS 

CC13  -  CC14 

12 

DELIVERED  FROM  TERMINALS  (1) 
AVERAGE  CAPACITY  OF  TERMINAL  (3) 

CC15  -  CC16 

12 

AVERAGE  NUMBER  OF  SHIPMENTS  IN 

CC17  -  CC18 

12 

ARRIVAL  QUEUE  (3) 

AVERAGE  NUMBER  OF  SHIPMENTS  IN 

CC19  -  CC80 

62X 

DEPARTURE  QUEUE  (3) 

BLANK 

THIRD  CARD 

CC  1  -  CC  5 

15 

NUMBER  OF  SECTORS  (DATA  SETS) 

CC  6  -  CC10 

F5.1 

TO  BE  SELECTED 

NUMBER  OF  HOURS  OF  TRAVEL  PER 

CC11  -  CC15 

15 

SIMULATION  TIME  PERIOD 

NUMBER  OF  TERMINALS  RESERVED  FOR 

CC16  -  CC20 

F5.1 

SCENARIO  DEFINITION  IN  LOGATAK 
NUMBER  OF  SIMULATION  TIME 

CC21  -  CC80 

60X 

PERIODS  PER  DAY 

BLANK 

SECTOR  (DATA  SET)  CARDS 

CC  1  -  CC10 

no 

SECTOR  (DATA  SET)  IDENTIFICATION 

CC11  -  CC80 

no 

NUMBERS  IN  INCREASING  ORDER 

CC71  -  CC80 
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sector  can  be  specified  oy  a  zero  in  the  units  digit.  All  data  set  identi¬ 
fier  numbers  must  he  ordered  beginning  with  the  smallest  number.  A  nega¬ 
tive  identifier  number  causes  all  associated  link,  data  to  have  a  negative 
capacity  indicating  the  link  is  inactive.  In  addition  information  on  the 
inactive  links  is  stored  on  a  separate  file  to  be  punched.  These  resulting 
punched  cards  can  be  utilized  by  the  LOGATAK  user  to  "turn  on"  the  inactive 
1  inks. 

1 . 5  Job  Control 

Eight  files  are  accessed  by  DAMSEL  as  indicated  on  the  program 
card.  Utilization  of  the  files  is  shown  in  Table  1 1 1-4. 

The  DAMSEL  program  is  currently  operating  on  a  Control  Data 
Corporation  6000  series  computer.  The  UPDATE  program  for  maintaining  and 
updating  source  decks  on  libraries  in  compressed  symbolic  format  is  uti¬ 
lized  in  the  operation  of  DAMSEL.  Figure  1 1 1-2  shows  the  control  cards 
used  to  place  the  DAMSEL  program  on  the  new  program  library. 

The  job  control  cards  necessary  for  program  execution  once  the 
program  is  on  the  library  is  shown  in  Figure  1 1 1-3.  Temporary  alterations 
to  the  DAMSEL  program  may  be  made  as  needed  via  the  UPDATE  procedures. 

2.  OUTPUT 

2. 1  General 

Program  DAMSEL  provides  direct  output  in  two  basic  forms; 
(1)  printed,  and  (2)  permanent  file.  The  printed  output  informs  the  ana¬ 
lyst  what  operations  the  program  has  performed  and  provides  a  catalog  of 
the  data  when  selected  for  analysis.  Output  which  will  be  used  again  by 
DAMSEL  or  is  formatted  for  use  by  LOGATAK  is  stored  on  permanent  files. 

2. 2  Printed  Output 

2.2.1  Data  Library  Alterations 

When  alterations  are  made  to  the  data  library  a  printed  summary 
of  the  alterations  is  provided.  An  example  of  this  output  is  shown  in 
Figure  1 1 1-4. 


TABLE  III-4.  DAMSEL:  FILE  UTILIZATION 


UTILIZATION 


DATA  LIBRARY 
WORKING  FILE 
WORKING  FILE 
CARD  INPUT 
PRINTED  OUTPUT 
TERMINALS  &  LINKS  SELECTED 
&  FORMATTED 

"TURN  ON"  FOR  INACTIVE  LINKS 
NEW  DATA  LIBRARY 
(IF  CREATED) 


(JOB  CARD) 

REQUEST, NEWPL,*PF, 

UPDATE (P,N,F) 

CATALOG(NEWPL, DAMSEL  PROGRAM,  ID=LGKAV) 
FTN( I=COMPILE) 

7/8/9  END-OF-RECORD 
*DECK  OAMSEL 

(DAMSEL  PROGRAM  INSERTED  HERE) 
6/7/8/ 9  END-OF- INFORMATION 


Figure  I I 1-2-  DAMSEL  Program  File  Creation  Job  Control 
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(JOB  CARD) 

ATTACH (OLDPL, DAMSEL  P ROGRAM , I D= LGKAV ) 

UPDATE(F) 

ATTACH(TAPE2 , DATA  LIBRARY , ID=LGKAV ) 

REQUEST, TAPE8,*PF. 

REQUEST, TAPE10,*PF. 

FTN( I=COMPILE) 

LGO. 

CATAL0G(TAPE8 , LOGATAK  INPUT ,  ID=LGKAV) 

CATALOG(TAPE 1 0 , NEW  DATA  LIBRARY , ID=LGKAV) 

REWIND, TAPE8. 

C0PYSBF(TAPE8, OUTPUT) 

REWIND, TAPE9. 

C0PYBF(TAPE9, PUNCH) 

REWIND, TAPEIO. 

C0PYSBF(TAPE10 .OUTPUT) 

7/8/9  ENO-OF-RECORD 

(TEMPORARY  DAMSEL  PROGRAM  CHANGES  INSERTED  HERE) 
7/8/9  END-OF-RECORD 

(INPUT  DATA) 

6/7/8/9  END-OF- INFORMAT  ION 


Figure  1 1 1 - 3 .  DAMSEL  Execution  Job  Control 
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2.2.2  Data  Selection 

The  first  printed  output,  see  Figure  I I I - 5 ,  wnen  selecting  lata 
is  a  list  of  the  input  used  for  selection  identification.  The  "turners 

identify  the  location  and  mode  of  the  data  to  be  selected.  A  minus  sign 
indicates  that  data  selected  in  this  sector  shall  be  initially  inactive. 

The  list  of  terminals  selected  are  orintea  as  shown  in 

Figure  lll~6.  The  first  terminal  numDer  is  used  oy  LOGATAK  and  is  unique 

only  for  this  selection  of  data.  The  second  terminal  number  is  from  the 

data  base  and  uniquely  represents  the  associated  terminal. 

Following  the  list  of  terminals  is  the  list  of  associated  links. 
Figure  III-7.  The  two  sets  of  terminal  numbers  define  the  end  points  of 
the  linKS  and  are  consistent  with  the  terminal  numbers  identified  above. 

Finally,  as  shown  in  Figure  III-8,  is  the  summary  of  the  data 
selection  operation  of  program  DAMSEL. 

2.  3  Permanent  File  Output 

2.3.1  Data  Library  Alterations 

Whenever  alterations  are  made  to  the  data  library  the  updated 
library  is  output  onto  a  permanent  file.  The  library  is  maintained  in  an 
ordered  fashion  which  simplifies  the  alteration  and  selection  processes. 
Samples  of  the  data  library  are  shown  in  Figure  III-9. 

2.3.2  Data  Selection 

Data  which  is  selected  for  analysis  is  properly  formatted  for  use 
by  LOGATAK  stored  on  permanent  file.  This  file  is  utilized  to  create  an 
UPDATE  file  of  input  data  for  LOGATAK.  To  this  UPDATE  file  must  be  added 
the  other  LOGATAK  inputs  described  in  Chapter  IV,  and  the  scenario  depend¬ 
ent  data  outlined  in  Chapter  II.  The  scenario  dependent  data  describes  the 
locations  of  the  supply  points  and  demand  generators.  These  locations  are 
tied  into  the  geographic  network  through  additional  links.  Links  are 
defined  for  all  positions  of  the  scenario  and  are  formatted  as  described  in 
Table  IV- 3 .  A  sample  of  this  file  is  shown  in  Figure  III-10. 

Some  of  the  data  selected  is  initially  inactive  (i.e.,  links  have 
negative  capacity).  A  permanent  file  is  created  which  contains  all  infor¬ 
mation,  except  time  of  "turn  on",  necessary  to  activate  these  links  in  the 
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Figure  1 1 1-5.  DAMSEL  Data  Selection  List 
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Figure  1 1 1 -6 .  DAMSEL:  Selected  Terminals 
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Figure  III-7.  DAMSEL:  Selected  Links 


Figure  III-8.  DAMSEL:  Selection  Summary 
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Figure  III-10.  DAMSEL:  Data  Formatted  for  LOGATAK 


LOGATAK  simulation.  This  permanent  file  can  be  converted  to  punched  cards 
(CHNET  cards,  see  Table  IV— 11)  and  utilized  as  input  to  LOGATAK.  Qniy  the 
"turn  on"  time  needs  to  be  added  in  card  columns  il-20. 


CHAPTER  IV 
LQGATAK  INPUTS 


1.  GENERAL  DESCRIPTION 

The  user  must  describe  the  transoortation  network,  the  supoly 
nodes,  the  classes  of  supply,  and  the  ueiay  distributions  used  in  the 
simulation.  In  addition,  changes  can  be  made  to  most  of  the  parameters 
during  the  course  of  a  simulation  run  and  attacks  on  the  transportation 
network  can  be  made  at  any  time.  The  input  data  for  the  LOGATAK  model  is 
read  by  the  modules  DATAN,  RDNET,  INITP,  INPAR,  and  FILE  at  the  beginning 
of  the  model  run.  Data  to  change  the  transportation  network  (CHNET), 
change  distribution  parameters  (CHPAR),  change  supply  parameters  (CHPRM), 
attack  supply  inventories  (ATSUP),  attack  the  network  (ATACK),  and  jam  | 

communications  (CCCUB),  are  read  in  during  the  model  run  in  the  order  and 
at  times  prespecified  in  the  DATAN  input.  Figure  IV- 1  shows  a  schematic  of 
the  input  stream  for  the  LOGATAK  model. 

This  chapter  describes  the  input  data  and  the  data  formats 
required  in  each  of  the  above  specified  areas.  The  deck  to  restart  the 
model  from  a  previously  saved  position  is  also  described. 

2.  MODEL  PARAMETERS 

The  first  cards  in  a  model  run  specify  general  model  parameters. 

Table  IV- 1  shows  the  format  for  the  five  card  types  that  are  read  by  the 
module  DATAN.  They  are  self-explanatory  with  the  possible  exception  of  the 
Exogenous  Events  Cards.  These  cards  are  the  primary  method  of  scheduling 
events  within  the  model.  (Future  events  may  also  be  scheduled  during  the 
run  in  the  CHNET  and  ATACK  card  decks.)  The  end  of  simulation  event  and 
the  warmup  event  are  alternatives  to  the  time  specifications  on  the  Control 
Parameters  Card.  KTRACE  is  a  trace  of  logical  events  in  the  model  and 
LTRACE  is  a  detailed  trace  of  the  internal  linkage  between  modules.  Both 
traces  may  be  turned  on  or  off  at  any  time  during  the  simulation.  The  save 
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rABLE  IV- 1.  MODEL  PARAMETER  CARD  FORMATS 


RUN 

TYPE  CARD  FORMAT 

COLUMN 

FORMAT 

DESCRIPTION 

1-10 

10X 

ENTER  LOGATAK 

n-20 

F10.0 

CENTRAL  PROCESSOR  TIME  LIMIT  MINUS 

REPORT  TIME 

21-30 

F10.0 

RESTART  SWITCH 

.  LE.  0  -  NORMAL  START 
.GT.  0  -  RESTART 

MODEL  AND  RUN  IDENTIFIERS  CARD  FORMAT 

COLUMN 

FORMAT 

DESCRIPTION 

1-12 

A12 

ANALYST  NAME 

13-16 

14 

PROJECT  NUMBER 

17-18 

12 

MONTH 

19-20 

12 

DAY  OF  THE  MONTH 

21-24 

14 

YEAR 

25-28 

14 

NUMBER  OF  CYCLES  OF  THE  SIMULATION  IN 
THIS  RUN 

29-40 

A12 

MODEL  NAME 

41-58 

A18 

RUN  NrtME 

59-80 

22X 

BLANK 

UNIT 

LABELS  CARD  FORMAT 

COLUMN 

FORMAT 

DESCRIPTION 

1-6 

A6 

UNIT  OF  TIME 

7-12 

A6 

UNIT  OF  WEIGHT 

13-18 

A6 

UNIT  OF  CUBE 

19-24 

A6 

UNIT  OF  DISTANCE 

25-80 

56X 

BLANK 
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TABLE  IV- i.  MODEL  PARAMETER  CARD  FORMATS  (CONTINUED) 


- j 

CONTROL  PARAMETERS  CARO  FORMAT  j 

COLUMN 

FORMAT 

DESCRIPTION  j 

1-5 

15 

STOPPING  RULE  SWITCH  (MSTOP)  - 

.EQ.  0  -  STOP  SIMULATION  WHEN 

EVENT  ENDSM  (EVENT  CODE  -1) 

IS  ENCOUNTERED 

.GT.  0  -  STOP  SIMULATION  WHEN 

SIMULATED  TIME  EXCEEDS  ENDING 

TIME  TFIN 

6-15 

1  OX 

BLANK 

16-20 

15 

VARIABLE  NEP,  ENTER  1 

21-30 

F10.3 

TBEG,  INITIAL  VALUE  OF  SIMULATED  TIME 

31-40 

F10.3 

TFIN,  LARGEST  VALUE  OF  SIMULATED  TIME 

TO  BE  REPRESENTED  IF  MSTOP  .GT.  0 

41-50 

F10.3 

TWARM,  SIMULATED  TIME  AT  WHICH  STA¬ 
TISTICAL  ARRAYS  ARE  TO  BE  CLEARED 

51-54 

14 

RANDOM  NUMBER  SEED 

55-80 

25X 

BLANK 

EXOGENOUS 

EVENTS  CARD  FORMAT* 

COLUMN 

FORMAT 

DESCRIPTION 

1-8 

18 

ENTER  1,  THE  NUMBER  OF  THE  GASP  TIME  FILE 

9-17 

F9.3 

SIMULATION  TIME  AT  WHICH  EVENT  SHOULD  OCCUR 

18-20 

3X 

BLANK 

21-23 

13 

EVENT  CODE 

-1  END  OF  SIMULATION  EVENT 
-2  KTRACE 

-3  LTRACE 

-4  WARMUP  EVENT 

-5  SAVE  RUN  EVENT 

-6  CORE  REPORT 

-8  EXECUTE  A  ZINIT  SUBNODE 

-99  EXECUTE  TARGAA 

24-26 

3X 

BLANK 

27-35 

F9.3 

ATTRIBUTE  3  OF  EVENT.  ZINIT  SUBNODE 

NUMBER  IF  EVENT  CODE  IS  -8.  NUMBER  OF 

BOMBS  AVAILABLE  IF  EVENT  CODE  IS  -99. 
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TABLE  IV- 1.  MODEL  PARAMETER  CARD  FORMATS  (CONTINUED) 


COLUMN 

FORMAT 

DESCRIPTION 

36-44 

F9.3 

ATTRIBUTE  4  OF  EVENT. 

SWTICH  TO  RESCHED- 

ULE  TARGAA  IF  EVENT 

CODE  IS  -99.  (O-NO. 

I -YES ) 

I 

45-53 

F9.3 

ATTRIBUTE  5  OF  EVENT. 

TIME  DELAY  FOR 

TARGAA  RESCHEDULING 

IF  EVENT  CODE  IS  -99. 

54-62 

F9.3 

ATTRIBUTE  6 

63-71 

F9.3 

ATTRIBUTE  7  (ATTRIBUTES  3-8  ARE  GENERALLY 

BLANK) 

72-80 

F9.3 

ATTRIBUTE  8 

*  THE  SUBDECK 

OF  EXOGENOUS  EVENTS  CARDS  MUST  BE  HEADED 

BY  A  CARD  CONTAIN- 

ING  -1  IN  COLS  7- 

■8  TO  CAUSE 

INITIALIZATION  OF  ARRAY  SETS 

AND  IS  ENDED  WHEN 

A  CARO  WITH  0  IN 

COL  8  IS  ENCOUNTERED. 
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run  event  causes  all  model  data  values  to  be  placed  on  CILE3  r'or  use  in 
restarting  the  model  *rom  that  point  in  simulated  time.  The  core  *-eoort 
request  causes  a  short  report  on  <ey  array  utilization  in  the  modei.  Each 
of  the  above  events  requires  only  the  time  of  occurrence  and  the  event  code 
attributes  to  be  specified  on  the  card. 

The  other  two  event  codes  require  additional  attributes  to  be 
SDecified.  The  -8  event  code  causes  the  Z I  NIT  subnode  with  the  numoer  in 
attribute  3  to  be  executed.  Table  IV- 2  lists  the  3vailaole  options  in 
LOGATAK.  The  -99  event  code  causes  the  Target  Allocation  Algorithm 
(TARGAA)  to  be  executed.  A  list  of  preferred  targets  will  be  printed  out 
and  the  number  of  bombs  specified  in  attribute  3  will  be  used  to  schedule 
attacks.  TARGAA  can  be  rescheduled  periodically  by  setting  the  values  in 
attributes  4  and  5. 

3.  TRANSPORTATION  NETWORK 

The  links  and  terminals  of  a  transportation  network  and  all  their 
characteristics  are  defined  in  the  RDNET  input  data  deck  at  the  beginning 
of  the  model  run.  Table  IV-3  shows  the  formats  for  the  five  types  of  RDNET 
cards;  FILE,  LINK,  TERM,  MODE,  and  END.  Figure  IV-2  shows  the  input  card 
order  for  the  RDNET  deck.  The  FILE  card  is  always  read  from  FILE5,  the 

card  reader  and  all  subsequent  cards  are  read  from  the  file  specified  on 

the  FILE  card.  This  permits  a  voluminous  RDNET  deck  to  be  placed  on  a 

separate  file.  For  most  efficient  core  utilization,  terminals  should  be 
numbered  consecutively,  starting  with  33.  The  first  30  terminals  are 
automatically  assigned  to  the  5  sources  of  supply,  the  5  intermediate 
supply  points,  and  the  20  demand  generators  in  the  model.  Terminals  31  and 
32  are  assigned  for  use  by  TARGAA  as  artificial  source  and  artificial  sink 
terminals. 

TERM  cards  and  LINK  cards  can  be  intermixed  in  the  deck.  The 
read  operation  ceases  when  an  END  card  is  encountered.  For  initial  execu¬ 
tion  of  RDNET,  the  six  MODE  cards  are  read.  For  subsequent  executions  of 
RDNET  (TNOW. NE.  TBEG) ,  the  MODE  cards  are  not  required.  The  links  in  a 
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TABLE  IV— 2.  UNIT  SUBNOOES  WHICH  CAN  BE  SCHEDULED  EXOGENOUSLY 


SUBNODE 

NUMBER 

2 

3 

4 

5 

6 

8 

9 

10 

11 


PURPOSE 

RDNET  -  ADDITIONS  TO  THE  TRANSPORTATION  NETWORK  DURING 
THE  MODEL  RUN 

CHNET  -  CHANGE  THE  TRANSPORTATION  NETWORK  PARAMETERS 

ATACK  -  ATTACKS  ON  THE  TRANSPORTATION  NETWORK 

CHPRM  -  CHANGE  THE  SUPPLY  PARAMETERS 

CHPAR  -  CHANGE  THE  DELAY  DISTRIBUTION  PARAMETERS 
(PARAMS) 

INTERIM  SUPPLY  REPORT 

INTERIM  TRANSPORTATION  REPORT 

ATSUP  -  ATTACK  SUPPLY 
CCCUB  -  COUNTER  -  C3 
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SHPMT  -  EXOGENOUS  SHIPMENTS 
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TABLE  IV-3.  RDNET  DATA  CARD  FORMATS 


SET  OF  DATA  CARDS  FOR  DESCRIBING  ..INKS  AND  'ERMINALS  IN  A  'RANSPQRTAT ION  ! 

NETWORK  FOR  A  MODEL  RUN.  CONTINUOUS  READ  UNTIL  lAST  CARD  VI TH  END  CARD 

TYPE  DESIGNATION.  SUBSEQUENT  CARDS  READ  FROM  FILE  SPECIFIED  ON  FIRST  CARD. 

FILE  DEFINITION  CARD  - 

- - - - - -  " 

ALL  SUBSEQUENT  CARD  IMAGES  ARE  READ  cROM 

THE  FILE  SPECIFIED 

CC1  -CCS 

A5 

CARD  NAME  -  RDNET 

CC6  -CCIO 

A5 

CARO  TYPE  -  FILE 

CC11-CC20 

no 

FILE  NUMBER 

CC21-CC80 

60X 

BLANK 

LINK  DEFINING 

CARD  - 

CC 1  -CC5 

A5 

CARD  NAME  -  RDNET 

CC6  -CCIO 

A5 

CARD  TYPE  -  LINK  OR  END,  LEFT  JUSTIFIED 

CC 1 1 -CC  T  5 

15 

TERMINAL  NUMBER 

CC16-CC20 

15 

TERMINAL  NUMBER 

CC21-CC30 

F10.3 

LENGTH  OF  LINK 

CC31-CC40 

F10.3 

CAPACITY  OF  LINK  IN  WEIGHT  UNITS  (NEGATIVE 

SIGN  INDICATES  THAT  THE  LINK  IS  NOT  CURRENTLY 
ACTIVE) 

CC41-CC45 

F5.0 

VULNERABILITY  FACTOR 

CC46-CC50 

F5.0 

TIME  TO  REBUILD 

CC51-CC55 

F5.0 

RATE  OF  TRAVEL  ON  LINK 

CC56-CC60 

15 

MODE  OF  LINK 

CC61-CC70 

IOX 

NOT  USED 

CC71-CC72 

12 

STATIX  -  AVG.  TONS  ON  LINK  (3) 

CC73-CC74 

12 

STATIX  -  TOTAL  TONS  OVER  LINK  (1) 

CC75-CC76 

12 

STATIX  -  AVG.  CAPACITY  OF  LINK  (3) 

CC77-CC80 

4X 

NOT  USED 

1  TERMINAL  DEFINING  CARD 

- 

CC1  -CC5 

A5 

CARD  NAME  -  RDNET 

CC6  -CCIO 

A5 

CARD  TYPE  -  TERM,  LEFT  JUSTIFIED 

CC11-CC15 

15 

TERMINAL  NUMBER 

CC16-CC20 

15 

MODE  OF  TERMINAL 

CC21-CC30 

F10.3 

NOT  USED  ON  TERM  CARD 

CC31-CC40 

FIO.  3 

CAPACITY  OF  TERMINAL  (NEGATIVE  SIGN  INDICATES 
THAT  THE  TERMINAL  IS  NOT  CURRENTLY  ACTIVE) 

CC41-CC45 

F5.0 

VULNERABILITY  FACTOR 

CC46-CC50 

F5.0 

TIME  TO  REBUILD 

INDEX  TO  PROBABILITY  DISTRIBUTIONS  FOR  DELAY  - 

CC51-CC55 

15 

-  SHIPMENT  CONSOLIDATION  (NEGATIVE 

VALUE  CAUSES  CHANGE  IN  SHIPMENT  SIZE) 

CC56-CC60 

15 

-  LOADING 

■'ABLE  IV- 3.  RDNET  DATA  CARD  FORMATS  (CONTINUED) 


CC61-CC65 

15 

-  TERMINAL  THROUGHPUT  (NEGATIVE  VALUE 

FORCES  ROUTE  RECOMPUTATION) 

CC66-CC70 

IS 

-  UNLOADING 

CC71-CC72 

12 

STATIX  -  AVG.  TONS  IN  THIS  TERMINAL  (3) 

CC73-CC74 

12 

STATIX  -  TOTAL  TONS  THROUGH  TERMINAL  ( 1 ) 

CC75-CC76 

12 

STATIX  -  TOTAL  TONS  DELIVERED  FROM  TERM.  (1) 

CC77-CC78 

12 

STATIX  -  AVG.  CAPACITY  OF  THIS  TERMINAL  (3) 

CC  79 

n 

STATIX  -  AVG.  NO.  OF  5HIPMENTS-ARRIVAL  0  (3) 

CC80 

n 

STATIX  -  AVG.  NO.  OF  SHIPMENTS-DEPART.  0  (3) 

MODE  DEFINITION  CARD  - 

USED  ONLY  FOR  INITIAL  RDNET  IN  MODEL 

CC1  -CCS 

A5 

CARD  NAME  -  RDNET 

CC6  -CCIO 

A5 

CARD  TYPE  -  MODE 

CC11-CC15 

15 

MODE  CODE  -  ONE  CARD  FOR  EACH  MODE  TYPE 

CC16-CC20 

5X 

NOT  USED 

CC21-CC30 

F10.3 

MAXIMUM  NUMBER  OF  WEIGHT  UNITS  THAT  CAN  BE 

CARRIED  IN  THIS  MODE  AT  ONE  TIME 

CC31-CC40 

F10.3 

MAXIMUM  NUMBER  OF  CUBE  UNITS  THAT  CAN  BE 

CARRIED  IN  THIS  MODE  AT  ONE  TIME 

CC47-CC50 

FT  0.  3 

STATIX  -  TOTAL  UNITS  OF  WEIGHT  TIMES  UNITS 

OF  DISTANCE  TRANSPuRTED  IN  THIS  MODE  (1) 

CC51-CC80 

30X 

NOT  USED  FOR  MODES  2-6. 

FOR  MODE  1 

CC51-CC55 

15 

LOWEST  PRIORITY  SHIPMENT  THAT  CAN  TRVL  BY  AIR 

CC56-CC60 

15 

UPPER  LIMIT  ON  ARRIVAL  QUEUE  SIZE 

CC61-CC65 

15 

UPPER  LIMIT  ON  DEPARTURE  QUEUE  SIZE 

CC66-CC70 

15 

STATIX  -  TOTAL  SHIPMENTS  SENT  ALL  MODES  (1) 

CC71-CC75 

15 

STATIX  -  TOTAL  SHIPMENTS  LOST  ALL  MODES  (1) 

CC76-CC80 

15 

STATIX  -  TOTAL  SHIPMENTS  DELIVERED  ALL  MODES  (1) 
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Figure  IV-2.  Input  Setup  for  RDNET  Module 
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transportation  network  are  defined  by  the  terminals  at  each  end.  The  mode i 
orders  and  numbers  the  link  for  ease  of  access  arter  reading  all  RDNETLINK 
cards.  RDNET  can  be  used  later  in  a  model  run  to  read  in  additional  termi¬ 
nals  and/or  links.  This  causes  a  renumbering  of  the  linxs  and  the  model 
prints  a  table  showing  the  cross  reference  from  the  old  to  the  new  link 
numbering. 

The  first  30  terminals  must  be  linked  into  the  network  at  the 
desired  terminals  to  specify  the  geographic  location  of  the  supply  nodes. 
A  supply  node  terminal  may  be  linked  in  at  a  number  of  different  points  in 
the  network  to  show  different  geographic  locations  over  time.  In  this 
case,  all  but  one  of  the  links  should  have  a  negative  capacity,  indicating 
that  they  are  inactive  at  the  current  time.  They  can  subsequently  be 
"turned  on"  in  turn  with  the  CHNET  capability. 

4.  SUPPLY  PARAMETERS 

The  characteristics  of  supply  classes  and  supply  nodes  are  speci¬ 
fied  on  INITP  cards.  These  cards  initialize  permanent  attribute  data  sets 
in  the  model  and  are  quite  flexible  in  format  and  use.  Some  portion  or  all 
of  the  supply  nodes  may  be  utilized  in  any  given  model  run.  One  or  more 
classes  of  supply  can  be  represented  at  each  supply  node  by  preparing  one 
or  more  INITP  cards  of  the  proper  type.  In  general,  there  is  no  fixed 
limit  on  the  number  of  classes  represented  at  any  node  in  the  model.  The 
supply  characteristics  of  each  node  in  the  model  are  specified  by  a  group 
of  INITP  cards.  The  formats  for  the  three  INITP  card  types  are  shown  in 
Table  IV-4.  Card  type  INITP!  is  generally  blank  in  CC7-CC80,  but  it  does 
offer  a  method  for  specifying  data  for  a  number  of  supply  classes  or 
resources  by  grouping  them  into  a  resource  set.  The  resource  set  identifi¬ 
cation  number  is  then  used  in  INITP2  cards  which  causes  duplication  of  the 
data  sets  for  all  resources  in  the  set. 

4. 1  ***ALL  Node  Data 

A  supply  item  common  (SICOM)  data  set  must  be  specified  for  each 
item  or  supply  class  which  is  represented  in  the  model  run.  Each  item  must 


TABLE  IV-4.  iNITP  DATA  CARD  FORMATS 


PERMAT  INPUT  DATA 


CARD  TYPE 

1  -  RESOURCE  SET  DEFINITION  CARD 

COLUMN 

FORMAT 

DESCRIPTION 

1  - 

6 

A6 

ENTER  INITP1 

7  - 

14 

8X 

IGNORED 

15  - 

20 

16 

RESOURCE  SET  IDENTIFICATION 

NUMBER 

21  - 

26 

6X 

IGNORED 

27  - 

28 

12 

CARO  SEQUENCE  NUMBER  (OPTIONAL)  i 

29 

IX 

BLANK 

30  - 

31 

12 

NUMBER  OF  RESOURCE  NUMBERS 

IN  THIS  SET 

32 

IX 

BLANK 

33  - 

38 

F6.0 

FIRST  RESOURCE  NUMBER 

39  - 

44 

F6.0 

SECOND  RESOURCE  NUMBER 

75  - 

80 

F6.0 

EIGHTH  RESOURCE  NUMBER 

ADDITIONAL  RESOURCE 

NUMBERS  WILL 

BE  READ  FROM  SUCCEEDING  CARDS 

UNTIL  A 

DIFFERENT 

RESOURCE 

SET  NUMBER  IS 

ENCOUNTERED  IN  CC  15  -  20.  THE  NUMBER 

OF  RESOURCE  NUMBERS 

IS  LIMITED  TO 

2000  FOR  ALL  SETS. 
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TABLE  IV-4.  INITP  DATA  CARD  FORMATS  (CONTINUED) 


THE  SUBDECK  OF  ALL  TYPE  !  CAROS  IS  FOLLOWED  3Y  A  SERIES  OF  SUBDECKS  (EACH 
CONTAINING  ONE  TYPE  2  CARD  AND  A  NUMBER  OF  TYPE  3  CARDS),  ONE  FOR  EACH 
NODE  THAT  REQUIRES  PERMAT  DATA  AND  ONE  FOR  DATA  COMMON  TO  ALL  NODES. 


CARD  TYPE  2  - 

NODE 

IDENTIFICATION 

CARO  OR  END  CARD 

COLUMN 

FORMAT 

DESCRIPTION 

1  -  6 

A6 

ENTER  INITP2 

7 

IX 

BLANK 

8  -  13 

A6 

NODE  NAME  OR  ***ALL  OR  ***END 

14  -  80 

66X 

IGNORED 

CARD  TYPE  3  - 

ATTRIBUTE  SET  VALUES  CARD 

COLUMN 

FORMAT 

DESCRIPTION 

1  -  6 

A6 

ENTER  INITP3 

7 

IX 

BLANK 

8  -  13 

A6 

RESOURCE  FUNCTION 

14 

IX 

BLANK 

15  -  20 

16 

RESOURCE  NUMBER  OR  RESOURCE  SET  NUMBER 

21 

IX 

BLANK 

22  -  26 

A5 

FUNCTION  TYPE  (E.G. ,  SNOD,  UNOD,  .  .  .) 

27  -  28 

12 

CARD  SEQUENCE  NUMBER  (OPTIONAL) 

29 

IX 

BLANK 

30  -  31 

12 

NUMBER  OF  ATTRIBUTES  IN  SET  (.LE.  20) 

32 

IX 

BLANK 

33  -  38 

F6.0 

1ST,  9TH,  AND  17TH  ATTRIBUTE  VALUES 

39  -  44 

F6.0 

2ND,  10TH,  AND  18TH  ATTRIBUTE  VALUES 

76  -  80 

F6.0 

8TH  AND  16TH  ATTRIBUTE  VALUES 

IF  MORE  THAN 

8  ATTRIBUTE  VALUES  ARE  NEEDED  IN  A  SET  THEY  ARE  LISTED  ON  ONE 

OR  TWO  SUCCEEDING 

CARDS  WITH  THE 

SAME  FORMAT  AS  INDICATED.  CC  8-31  MAY  BE 

LEFT  BLANK  ON 

THE 

2ND  ANO  3RD  CARDS. 

be  given  a  uniaue  identification  numDer.  Table  IV- 5  defines  the  attributes 
for  the  SICOM  resource  function. 

4. 2  FSB  Node  Data 

The  FSB  nodes  are  the  top  source  of  supply  in  the  model.  Incom¬ 
ing  demands  are  filled  in  one  or  more  stages  to  simulate  delays  encoun¬ 
tered.  The  FSB  node  can  handle  the  same  items  or  classes  of  supply  as  the 
lower  supply  echelons  do  or  it  can  handle  "wholesale"  classes  which  are 
groups  of  items.  These  classes  are  specified  in  attribute  5  of  the  SICOM 
data  set.  Table  IV-6  shows  the  attributes  for  the  FILTM  data  set  which 
specify  the  delays  to  be  imposed  for  each  class  and  priority  pair. 
Table  IV-6  also  shows  the  attributes  for  the  PRI  (SNOD)  data  set  which 
specifies  the  priority  groupings  used  for  the  priorities  of  incoming 
demands . 

4. 3  ASB  Node  Oata 

The  intermediate  supply  bases  require  three  types  of  data  sets: 
supply  parameters  (SUPAR),  supply  item  statistics  (SUPIST),  and  demand 
statistics  (DSTAT).  Table  IV-7  defines  the  attributes  for  each  of  these 
data  sets.  The  key  information  specified  for  the  ASB  node  is  the  initial 
balance  on  hand  or  inventory  level.  The  ASB  node  will  handle  all  items  or 
classes  of  supply  for  which  there  are  SUPAR  data  sets  specified. 

4. 4  DSB  Node  Data 

The  DSB  nodes  are  the  lowest  level  supply  bases.  They  generate 
demands  on  the  supply  system  and  measure  the  response  of  the  system  to 
those  demands.  The  DSB  nodes  require  three  types  of  data  sets:  node 
parameters  (NODE),  supply  item  demand  generation  data  at  a  user  node 
(SIUNOD),  and  aggregate  demand  generation  data  (SAUNOD).  Table  IV-8 
defines  the  attributes  necessary  for  each  of  the  three  data  sets.  The  DSB 
node  will  generate  demands  periodically  for  as  many  items  or  classes  of 
supply  as  there  are  SIUNOD  data  sets.  The  SAUNOD  data  set  will  collect 
aggregate  statistics  for  all  the  items  at  the  node.  A  void  SAUNOD  card 
should  be  included  even  if  there  is  only  one  SIUNOD  card  since  a  model 
report  is  triggered  by  its  presence.  The  three  OSB  data  set  types  should 
be  defined  for  each  DSB  node  which  will  be  active  in  the  model  run.  The 
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TABLE  IV-5.  SICOM  ATTRIBUTES 


SICOM  (ITEM) 

- 

COMMON  SUPPLY  ITEM  DATA 

- 

ONE  SET  FOR  EACH  SUPPLY  ITEM  OR  CLASS 

IN  THIS  MODEL 

- 

USE  CARD  TYPE  INITP3 

ATTRIBUTES 

1 

- 

WEIGHT  OF  THE  ITEM/CLASS  UNIT 

2 

- 

CUBE  OF  THE  ITEM/CLASS  UNIT 

4 

- 

ITEM  TYPE  CODE  (1  -  CONSUMABLE  MATERIEL, 

2  -  UNIT  EQUIPMENT  AND  PERSONNEL) 

5 

- 

SOURCE  OF  SUPPLY  ITEM  IDENTIFICATION  NUMBER 
(GENERALLY  THE  SAME  AS  SICOM  ID  NUMBER) 

7 

- 

ITEM  SUPPLY  PRIORITY 
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TABLE  IV* 6.  FSB  NODE  DATA  CARD  ATTRIBUTES 


FILTM  (.CLASS ,  PRIORITY) 


SUPPLY  FILL  TIMES 

ONE  SET  FOR  EACH  ITEM  CLASS/PRIORITY  COMBINATION 
DEFINED  AT  THIS  NODE.  PRIORITY  CLASSES  DEFINED 
IN  RESID  PRI  (SNOD)  DEFINED  BELOW  SHOULD  BE  USED. 
USE  CARD  TYPE  INITP3 


ATTRIBUTES 


1  -  STAT.  IND.  -  NUMBER  OF  DEMANOS  AND  QUANTITY  DEMANDED  (3). 

2  -  STAT.  IND.  -  NUMBER  OF  SHIPMENTS  AND  QUANTITY  SHIPPED  (3). 

3  -  STAT.  IND.  -  TIME  TO  FILL  WEIGHTED  BY  QUANTITY  FILLED  (3). 

4  -  PROBABILITY  OF  A  COMPLETE  FILL  IN  ONE  STAGE 

5  -  PROBABILITY  OF  TWO  OR  FEWER  STAGES 

6  -  FRACTION  FILLED  IN  STAGE  TWO  IF  ONLY  TWO  STAGES  NEEDED 

7  -  INDEX  TO  RANDOM  VARIABLE  REPRESENTING  DELAY  TIME  TO  FILL  STAGE  TWO 

WHEN  ONLY  TWO  STAGES  NEEDED 

8  -  PROBABILITY  OF  THREE  OR  FEWER  STAGES 

9  -  FRACTION  FILLED  IN  STAGE  TWO,  IF  THREE  STAGES  NEEDED 

10  -  FRACTION  FILLED  IN  STAGE  THREE,  IF  THREE  STAGES  NEEDED 

1 1  -  INOEX  TO  SECOND  STAGE  DELAY  TIME  DISTRIBUTION  WHEN  THREE  STAGES 

NEEDED 

12  -  INDEX  TO  THIRD  STAGE  DELAY  TIME  DISTRIBUTION  WHEN  THREE  STAGES 

NEEDED 

13  -  PROBABILITY  OF  FOUR  OR  FEWER  STAGES 

14,  15,  16  -  FRACTIONS  FILLED  IN  SECOND,  THIRD,  AND  FOURTH  OF  FOUR 
STAGES 

17,  18,  19  -  INDEX  TO  SECONO,  THIRD,  AND  FOURTH  STAGE  DELAY  TIME 
DISTRIBUTIONS 


PRI  (SNOD)  -  SUPPLY  PRIORITY  CLASSES. 

-  ONE  CARD  REQUIRED  AT  THIS  NODE,  THIS  CARD  CONTAINS  PRIORITY 
VALUES,  SAME  AS  THE  SECOND  ARGUMENTS  OF  RESID  FILTM. 

-  USE  CARD  FORMAT  INITP3. 


ATTRIBUTES 

1  -  NUMBER  OF  PRIORITY  CLASSES  (I.E.,  NUMBER  OF  ENTRIES  FOLLOWING). 

2  -  UPPER  LIMIT  OF  FIRST  PRIORITY  CLASS 

3  -  UPPER  LIMIT  OF  SECOND  PRIORITY  CLASS 
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TABLE  IV- 7.  ASB  NODE  DATA  CARD  ATTRIBUTES 


SUPAR  (ITEM,  SNOD)  -  SUPPLY  ITEM  PARAMETERS 

-  ONE  CARD  FOR  EACH  ITEM/CLASS  STOCKED  AT  THIS  NODE 

-  USE  CARD  TYPE  INITP3 

ATTRIBUTES 

1  -  SERVICEABLE  BALANCE  ON  HAND 


SUPIST  (ITEM,  SNOD)  -  SUPPLY  ITEM  STATISTICS 

-  ONE  CARD  FOR  EACH  ITEM/CLASS  STOCKED  AT  THIS  NODE 

-  USE  CARO  TYPE  INITP3 

ATTRIBUTES 

1  -  STATISTICAL  INDEX  -  SERVICEABLE  BALANCE  ON  HAND  (3) 


DSTAT  (ITEM,  SNOD)  -  ITEM  DEMAND  STATISTICS 

-  ONE  CARO  FOR  EACH  ITEM/CLASS  STOCKED  AT  THIS  NODE 

-  USE  CARD  TYPE  INITP3 

ATTRIBUTES 

1  -  STATISTICAL  INDEX  -  NUMBER  OF  DEMANDS  RECEIVED  AND 

QUANTITY  DEMANDED  (3) 

2  -  STATISTICAL  INOEX  -  NUMBER  OF  DEMANDS  COMPLETELY 

FILLED  WITHOUT  DELAY  AND  QUANTITY  FILLED  (3) 

3  -  STATISTICAL  INDEX  -  NUMBER  OF  DEMANDS  PARTIALLY 

FILLED  AND  QUANTITY  FILLED  (3) 


61 


TABLE  IV-8.  DSB  NODE  DATA  CARD  ATTRIBUTES 


NODE  (NODTYP)  -  NODE  PARAMETERS 

-  ONE  SET  cqR  EACH  NODE  TYPE  DEFINED  AT  THIS  NODE 

-  USE  CARD  TYPE  INITP3 


ATTRIBUTES 

1  -  DEMAND  GENERATION  INTERVAL  IN  TIME  UNITS 

2  -  NODE  PRIORITY 


SIUNOD  (ITEM)  -  ITEM  DEMAND  GENERATION  DATA 

-  ONE  SET  NEEDED  FOR  EACH  ITEM  STOCKED  AT  THIS  NODE 

-  USE  CARO  TYPE  INITP3 


ATTRIBUTES 

1  -  INDEX  OF  DISTRIBUTION  OF  NUMBER  OF  DEMANDS  IN  A  DEMAND 

GENERATION  INTERVAL 

2  -  INDEX  OF  DISTRIBUTION  OF  QUANTITY  PER  DEMAND 

6  -  STAT.  IND.  -  NUMBER  AND  QUANTITY  OF  SUPPLY  REQUISITIONS 

SUBMITTED 

7  -  STAT.  IND.  -  QUANTITY  DUE  IN  FROM  SUPPLY  -  A  TMST  STATISTIC 

8  -  STAT.  IND.  -  DURATION  OF  DUE  INS  FROM  SUPPLY 

9  -  STAT.  IND.  -  NUMBER  AND  QUANTITY  OF  SUPPLY  SHIPMENTS  RECEIVED 


SAUNOO  -  AGGREGATE  DEMAND  GENERATION  DATA 

-  ONE  SET  REQUIRED  AT  THIS  NODE 

-  USE  CARO  TYPE  INITP3 


ATTRIBUTES 

6  -  STAT.  IND. 

7  -  STAT.  IND. 

8  -  STAT.  [NO. 

9  -  STAT.  INO. 


-  NUMBER  ANO  QUANTITY  OF  SUPPLY  REQUISITIONS 
SUBMITTED 

-  QUANTITY  DUE  IN  FROM  SUPPLY  -  TMST  -  TYPE 
STATISTIC 

-  OURATION  OF  OUE  INS  FROM  SUPPLY 

-  NUMBER  AND  QUANTITY  OF  SUPPLY  SHIPMENTS  RECEIVED 
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demand  frequency  and  quantity  demanded  are  soecifiea  for  the  nor*'?  oy  indi¬ 
rect  reference  to  the  distributions  in  the  INPAR  data  deck,  "his  allows 
many  nodes  to  use  the  same  distribution  if  desired. 

4.  5  INITP  Data  Deck 

Figure  IV-3  shows  the  input  deck  for  the  INITP  module.  Only 
those  supply  nodes  which  are  active  in  the  modei  require  data  cards  in  the 
deck.  The  subdecks  for  the  nodes  and  the  data  set  cards  within  each  sud- 
deck  may  be  placed  in  any  order.  Figure  IV-3  shows  one  such  ordering. 

5.  DELAY  DISTRIBUTIONS 

The  LOGATAK  Model  has  complete  flexibility  in  specifying  stochas¬ 
tic  delay  distributions  in  the  input  data  deck.  These  distributions  are 
read  in  by  the  INPAR  module.  The  INPAR  card  formats  are  shown  in 
Table  IV-9.  Note  that  not  only  the  parameters  of  the  distribution  but  also 
the  type  of  distribution  may  be  altered  in  the  input  data  deck. 

6.  ACTIVATING  DEMAND  GENERATION 


There  are  twenty  supply  demand  generator  nodes  available  in  the 
model.  Whether  and  when  they  are  activated  is  determined  by  the  cards 
input  to  the  FILE  module.  There  are  twenty  occurrences  of  the  module  FILE 
in  node  ZINIT,  indexed  1  through  20  to  correspond  to  demand  generator  nodes 
DSB01  through  DSB20.  The  format  of  cards  for  the  FILE  module  is  given  in 
Table  IV-10.  The  minium  deck  requires  20  FILE  cards  with  indices  1  to  20 
in  CC6-7  and  a  zero  in  CC10.  To  activate  a  node,  the  corresponding  FILE 
card  should  be  preceded  by  a  FILE  card  with  a  1  in  CC10  and  the  time  of 
activation  in  CC11-2Q.  Demand  generation  will  then  continue  periodically 
at  the  interval  specified  in  the  INITP3  NODE  card. 
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TABLE  IV- 9.  INPAR  DATA  CARD  FORMATS 


PROBABILITY  DISTRIBUTION  PARAMETERS 

CARD 

TYPE 

1  - 

NUMBER  OF  DISTRIBUTIONS  -  ONE  CARD  ONLY  REQUIRED  | 

COLUMN 

FORMAT 

DESCRIPTION  1 

1  - 

6 

A6 

ENTER  INPAR1 

7 

IX 

BLANK 

8  - 

12 

15 

NUMBER  OF  PROBABILITY  DISTS.  IN  MODEL 

13  - 

80 

68X 

BLANK 

CARD 

TYPE 

2  - 

DISTRIBUTION 

PARAMETER  CARDS  -  ONE  FOR  EACH  DIST. 

COLUMN 

FORMAT 

DESCRIPTION 

1  - 

6 

A6 

ENTER  INPAR2 

7 

IX 

BLANK 

8  - 

12 

A5 

DISTRIBUTION  TYPE  * 

13 

IX 

BLANK 

14  - 

16 

13 

DISTRIBUTION  INDEX  NUMBER  ** 

17 

IX 

BLANK 

18  - 

25 

F8.0 

FIRST  PARAMETER 

26  - 

33 

F8.0 

SECOND  PARAMETER 

34  - 

41 

F8.0 

THIRD  PARAMETER 

42  - 

49 

F8.0 

FOURTH  PARAMETER 

50  - 

80 

31 X 

BLANK 

*  - 

SEE 

FOLLOWING  TABLE  FOR  ALLOWABLE  TYPES  AND  PARAMETER. 

**  _ 

THE 

NUMBER  USED  IN  THE 

MODEL  DESCRIPTION  AND/OR  INPUT. 
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TABLE  IV-9.  INPAR  DATA  CARD  FORMATS  (CONTINUED) 


RANDOM  VARIABLE  TYPES 

AND  PARAMETERS 

NAME  FOR 

FIRST 

SECOND 

THIRD 

FOURTH 

DISTRIBUTION 

INPUT 

PARAM 

PARAM. 

PARAM. 

PARAM. 

NORMAL 

NORML 

MEAN 

MINIMUM 

MAXIMUM 

STANDARD 

DEVIATION 

LOGNORMAL 

LGNOR 

MEAN 

MINIMUM 

MAXIMUM 

STD.  DEV. 

ERLANG 

ERLNG 

MEAN 

MINIMUM 

MAXIMUM 

ERLANG 

PARAMETER 

POISSON 

POSSN 

MEAN 

MINIMUM 

MAXIMUM 

BLANK 

GEOMETRIC 

GEOMT 

MEAN 

MINIMUM 

MAXIMUM 

BLANK 

CONSTANT 

CONST 

VALUE 

BLANK 

BLANK 

BLANK 

EMPIRICAL 

TABLE 

BLANK 

NUMBER  OF 

BLANK 

TYPE 

DATA  ** 

POINTS  IN 

INDICATOR* 

DISTRIBUTION 

END-OF-DECK 

**END 

*  -  ENTER  0  IF  THE 

DISTRIBUTION 

IS  CONTINUOUS,  ENTER  1 

IF  THE  DISTRIBUTION 

IS  DISCRETE. 

**  -  WHEN  AN  EMPIRICAL  DISTRIBUTION  IS  USED,  THE  DIST.  PARAMETER 

CARD  MUST 

BE  IMMEDIATELY 

FOLLOWED  BY  A 

SERIES 

OF  TYPE  3  CARDS 

DEFINING 

THE  POINTS 

IN  THE  DISTRIBUTION. 

TABLE  IV— 9.  INPAR  DATA  CARD  FORMATS  (CONTINUED) 


CARD  TYPE 

3  - 

DISTRIBUTIONS  DESCRIBED  IN  TABULAR  FORM 

COLUMN 

FORMAT 

DESCRIPTION 

1  - 

6 

A6 

ENTER  INPAR3 

7  - 

3 

2X 

BLANK 

9  - 

14 

F6.0 

MINIMUM  VALUE  OF  DISTRIBUTION 

15  - 

18 

F4.4 

PROS.  THAT  MINIMUM  VALUE  WILL  OCCUR 

19  - 

24 

F6.0 

SECOND  POINT  IN  DISTRIBUTION 

25  - 

28 

F4.4 

PROBABILITY  THAT  THE  RANDOM  VARIABLE 

WILL  NOT  EXCEED  SECOND  VALUE  (CUMULATIVE 
PRQB. ) 

29  - 

34 

F6.0 

THIRD  POINT 

35  - 

38 

F4.4 

CUMULATIVE  PROBABILITY  OF  THIRD  POINT 

39  - 

44 

F6.0 

FOURTH  POINT 

45  - 

48 

F4.4 

CUMULATIVE  PROBABILITY  OF  FOURTH  POINT 

49  - 

54 

F6.0 

55  - 

58 

F4.4 

. 

59  - 

64 

F6.0 

. 

65  - 

68 

F4.4 

, 

69  - 

74 

F6.0 

SEVENTH  POINT 

75  - 

78 

F4.4 

CUMULATIVE  PROBABILITY  OF  SEVENTH  POINT 

79  - 

80 

2X 

BLANK 

CONTINUATION  CARD 

1  - 

6 

A6 

ENTER  INPAR3 

7  - 

8 

2X 

BLANK 

9  - 

14 

F6.0 

EIGHTH  POINT 

15  - 

18 

F4.4 

CUMULATIVE  PROBABILITY  OF  EIGHTH  POINT 

CONTINUED 

CODING  DISTRIBUTION 

POINTS,  SEVEN  TO  A  CARD,  USING  AS  MANY  CARDS 

AS  REQUIRED. 

THE  FIRST  POINT 

IN  THE  DISTRIBUTION  WHICH  HAS  A  CUM.  PROB.  OF 

1.0  IS  CONSIDERED  AS  THE  END 

OF  TABLE. 

I 
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TABLE  IV- 10.  FILE  DATA  CARD  FORMATS 


COLUMN 

FORMAT 

DESCRIPTION 

1  -  4 

A4 

ENTER  FILE 

5 

A1 

CARD  TYPE,  1  -  FIRST  CARD,  2  -  SECOND 

CARD 

5  -  7 

12 

INDEX  OF  REFERENCE  TO  FILE,  I.E. ,  VAL 

OF  ARGUMENT  IFIL 

8  -  10 

13 

ENTER  1,  THE  FILE  NUMBER  FOR  THE  TIME 

FILE 

11-20 

F10.0 

FIRST  ATTRIBUTE-TIME  OF  OCCURRENCE  IF 
ARGUMENT  OF  RTURN  IS  0,  TIME  TO  WHICH 
INCREMENT  OBTAINED  BY  RTURN  IS  TO  BE 

ADDED  TO  OBTAIN  TIME  OF  OCCURRENCE  IF 
ARGUMENT  OF  RTURN  IS  POSITIVE. 

21  -  30 

F10.0 

SECOND  ATRIB  OR  NINTH  ATRIB  ON  CARD  2 

31  -  40 

F10.0 

THIRD  ATRIB  OR  TENTH  ATRIB  ON  CARD  2 

41  -  50 

F10.0 

FOURTH  ATRIB  OR  ELEVENTH  ATRIB  ON  CARD  2 

51  -  60 

F10. 0 

FIFTH 

61  -  70 

F10.0 

SIXTH  ATRIB 

71  -  80 

F10.0 

SEVENTH  ATRIB 

THE  VERB  FILE  WILL 

CONTINUE 

TO  READ  EXOGENOUS  EVENT  CARDS  UNTIL  IT  ENCOUNTERS 

A  CARD  WITH  FILE  1 

IN  CC 1-5 

AND  A  0  OR  BLANK  IN  CC8-10.  FILE  2  CARDS  ARE 

OPTIONAL.  USE  ONLY 
AND  11. 

IF  NEEDED  TO  SET  NON-ZERO  VALUES  IN  ATRIBS  8,  9,  10, 

T 


7.  CHANGING  THE  NETWORK 

The  transportation  network  characteristics  may  be  changed  exogen¬ 
ously  at  any  time  during  the  simulation  model  run.  Any  previously  defined 
terminal  or  link  may  be  activated,  deactivated,  or  nave  its  probability  of 
destruction,  capacity,  and  time  to  rebuild  changed.  For  links,  the  rate  of 
travel  and  length  of  the  link  may  also  be  changed.  The  format  of  CHNET 
cards  is  specified  in  Table  IV-11.  A  deck  of  CHNET  cards  will  be  read 
whenever  subnode  number  3  of  node  ZINIT  is  executed  by  an  exogenous  event 
card  in  the  DATAN  deck.  The  actual  changes  will  occur  at  the  time  speci¬ 
fied  on  the  CHNET  card  for  the  particular  terminal  or  link.  Changes  to 
links  and  terminals  may  be  intermixed  in  the  CHNET  data  deck. 

8.  CHANGING  DISTRIBUTIONS 


The  probability  distributions  which  control  the  transportation 
delays  and  the  demand  patterns  from  the  users  (e.g. ,  quantity  per  demand, 
number  of  demands)  may  be  changed  or  be  newly  defined  at  any  time  during  a 
model  run.  Either  the  parameter  values  for  the  distribution,  the  type  of 
distribution  or  both  may  be  changed  with  the  CHPAR  module.  A  deck  of  CHPAR 
cards  will  be  read  whenever  subnode  6  of  node  ZINIT  is  executed  by  an 
exogenous  event  card  in  the  DATAN  deck.  The  actual  parameter  changes  will 
occur  at  the  time  the  CHPAR  cards  are  read  in.  The  format  of  CHPAR  cards 
is  shown  in  Table  IV-12. 

9.  CHANGING  SUPPLY  PARAMETERS 


Any  value  in  a  supply  parameters  permanent  attribute  set  that  was 
read  in  on  an  INITP  card  can  be  changed  during  the  model  run  utilizing  the 
CHPRM  module.  This  change  PERMAT  module  can  also  be  used  to  add  or  delete 
entire  data  sets  for  any  of  the  nodes  in  the  model.  This  feature  can  be 
used,  for  example,  to  add  a  supply  class  to  the  inventory  for  one  of  the 
supply  bases.  The  data  sets  and  their  attributes  are  defined  in  Section  D 
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TABLE  iV-il.  CHNET  DATA  CARD  FORMATS 


CARDS  TO  CHANGE  TRANSPORTATION  NETWORK  CHARACTERISTICS  - 

CC1  -  CC5 

A5 

CARD  NAME  (CHNET) 

CC6  -  CC7 

12 

PRIMARY  CARD-ENTER  ! 

CC8  -  CC10 

3X 

BLANK 

ccn  -  cczo 

FI  0.  0 

TIME  OF  CHANGE 

CC21  -  CC25 

15 

TERMINAL  NUMBER  OR  0  IF  LINK  NO.  IN 

CC26-30 

CC26  -  CC30 

15 

TERMINAL  NUMBER  OR  LINK  NUMBER  FOR 

LINK 

CHANGE  OR  0  FOR  TERMINAL  CHANGE 

CC31  -  CC40 

no 

TYPE  OF  CHANGE  REQUESTED  - 

-1  DEACTIVATE  LINK/TERMINAL 

0  SET  CHARACTERISTICS  OF  LINK/TERMINAL 

1  ACTIVATE  LINK/TERMINAL 

2  REBUILD  LINK/TERMINAL 

CC41  -  CC50 

F10.0 

NEW  RATE  OF  TRAVEL  ON  LINK 

CCS!  -  CC60 

no.  o 

NEW  CAPACITY  OF  LINK/TERMINAL 

CC61  -  CC70 

F10.0 

NEW  PROBABILITY  OF  DESTRUCTION 

CC71  -  CC80 

FT  0 . 0 

NEW  TIME  TO  REBUILD 

IF  LENGTH  OF  LINK 

IS  TO  BE 

CHANGED,  INCLUDE  A  SECOND  CARD  - 

CC1  -  CC5 

A5 

CARD  NAME  (CHNET) 

CC6  -  CC7 

12 

CONTINUATION  CARD-ENTER  2 

CC8  -  CC10 

3X 

BLANK 

ccn  -  cc2o 

F10.0 

NEW  LENGTH  OF  LINK 

IF  RATE,  CAPACITY, 

PROB.  OESTRUC.,  OR  TIME  TO  REBUILD  ARE  NOT  TO 

BE 

CHANGED  —  ENTER  A 

VALUE  OF 

-1. 

END  CARD 

CC1  -  CC5 

A5 

CARD  NAME  (CHNET) 

CC6  -  CC7 

12 

ENTER  0 

ccn  -  cc80 

73X 

BLANK 
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TA81E  IV- 12.  CHPAR  DATA  CARD  FORMATS 


COLUMN 

1  -  6 

7 

8-25 

26  -  30 

31  -  80 

FORMAT 

A6 

IX 

3A6 

15 

50X 

DESCRIPTION 

ENTER  CHPAR1 

BLANK 

NAME  OF  CHANGE  SET  (E.G.,  TIME, 

PURPOSE,  .  .  .) 

NON-FATAL  SWITCH  (0  -  ERRORS  ARE  FATAL, 

1  -  ERRORS  ARE  FLAGGED  ONLY) 

BLANK 

CARD  TYPE  2  - 

DISTRIBUTION 

PARAMETER  CARDS  -  ONE  FOR  EACH  DIST.  TO  BE 

CHANGED 

COLUMN 

FORMAT 

DESCRIPTION 

1  -  6 

A6 

ENTER  CHPAR2 

7 

IX 

BLANK 

8  -  12 

A5 

DISTRIBUTION  TYPE  * 

13 

IX 

BLANK 

14  -  16 

13 

DISTRIBUTION  INDEX  NUMBER  ** 

17 

IX 

BLANK 

18  -  25 

F8.0 

FIRST  PARAMETER 

26  -  33 

F8.0 

SECOND  PARAMETER 

34  -  41 

F8.0 

THIRD  PARAMETER 

42  -  49 

F8.0 

FOURTH  PARAMETER 

50  -  80 

31X 

BLANK 

*  -  SEE  FOLLOWING  TABLE  FOR  ALLOWABLE  TYPES  AND  PARAMETERS. 

**  -  THE  NUMBER  USED  IN  THE  MODEL  DESCRIPTION  AND/OR  INPUT. 
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TABLE  IV- 12.  CHPAR  DATA  CARD  FORMATS  (CONTINUED) 


RANDOM  VARIABLE  TYPES 

AND  PARAMETERS 

— 

NAME  FOR 

FIRST 

SECOND 

THIRD 

FOURTH 

DISTRIBUTION 

INPUT 

PARAM. 

PARAM. 

PARAM. 

PARAM. 

NORMAL 

NORML 

MEAN 

MINIMUM 

MAXIMUM 

STANDARD 

DEVIATION 

LOGNORMAL 

LGNOR 

MEAN 

MINIMUM 

MAXIMUM 

STD.  DEV. 

ERLANG 

ERLNG 

MEAN 

MINIMUM 

MAXIMUM 

ERLANG 

PARAMETER 

POISSON 

POSSN 

MEAN 

MINIMUM 

MAXIMUM 

BLANK 

GEOMETRIC 

GEOMT 

MEAN 

MINIMUM 

MAXIMUM 

BLANK 

CONSTANT 

CONST 

VALUE 

BLANK 

BLANK 

BLANK 

EMPIRICAL 

TABLE 

BLANK 

NUMBER  OF 

BLANK 

TYPE 

DATA  ** 

POINTS  IN 

INDICATOR* 

DISTRIBUTION 

END-OF-DECK 

**END 

*  -  ENTER  0  IF  THE 

DISTRIBUTION 

IS  CONTINUOUS,  ENTER  1 

IF  THE  DISTRIBUTION 

IS  DISCRETE. 

**  -  WHEN  AN  EMPIRICAL  DISTRIBUTION  IS  USED,  THE  DIST.  PARAMETER 

CARD  MUST 

BE  IMMEDIATELY 

FOLLOWED  BY  A 

SERIES 

OF  TYPE  3  CARDS 

DEFINING 

THE  POINTS 

IN  THE  DISTRIBUTION. 
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TABLE  IV- 12.  CHPAR  DATA  CARD  FORMATS  (CONTINUED) 


CARD  TYPE 

3  - 

DISTRIBUTIONS 

DESCRIBED  IN  TABULAR  FORM 

COLUMN 

FORMAT 

DESCRIPTION 

1 

- 

6 

A6 

ENTER  CHPAR3 

7 

- 

8 

2X 

BLANK 

9 

- 

14 

F6.0 

MINIMUM  VALUE  OF  DISTRIBUTION 

15 

- 

18 

F4.4 

PROBABILITY  THAT  MINIMUM  VALUE  WILL  OCCUR 

19 

- 

24 

F6.0 

SECOND  POINT  IN  DISTRIBUTION 

25 

- 

28 

F4.4 

PROBABILITY  THAT  THE  RANDOM  VARIABLE 

WILL  NOT  EXCEED  SECOND  VALUE  (CUMULATIVE 

PROB. ) 

29 

- 

34 

F6.0 

THIRD  POINT 

35 

- 

38 

F4.4 

CUMULATIVE  PROBABILITY  OF  THIRD  POINT 

39 

- 

44 

F6.0 

FOURTH  POINT 

45 

- 

48 

F4.4 

CUMULATIVE  PROBABILITY  OF  FOURTH  POINT 

49 

- 

54 

F  6.0 

55 

- 

58 

F4.4 

. 

59 

- 

64 

F6.0 

, 

65 

- 

68 

F4.4 

. 

69 

- 

74 

F6.0 

SEVENTH  POINT 

75 

- 

78 

F4.4 

CUMULATIVE  PROBABILITY  OF  SEVENTH  POINT 

79 

80 

2X 

BLANK 

CONTINUATION  CARD 

1 

- 

6 

A6 

ENTER  CHPAR3 

7 

- 

8 

2X 

BLANK 

9 

- 

14 

F6.0 

EIGHTH  POINT 

15 

• 

18 

F4.4 

CUMULATIVE  PROBABILITY  OF  EIGHTH  POINT 

CONTINUE 

CODING  DISTRIBUTION 

POINTS,  SEVEN  TO  A  CARD,  USING  AS  MANY  CARDS 

AS  REQUIRED. 

THE  FIRST  POINT  IN  THE  DISTRIBUTION  WHICH  HAS  A  CUM.  PROB. 

OF  1.0  IS 

CONSIDERED  AS  THE 

END  OF  TABLE. 

? 

i 
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of  this  cnapter.  The  format  of  CHPRM  cards  is  shown  in  Table  lV-i3.  Eacn 
CHPRM  deck  consists  of  a  CHRPM1  card  that  labels  lt,  followed  by  a  sequence 
of  CHPRM2  cards  that  specify  the  data  set  to  be  changed  by  node  name  and 
data  set  name.  If  more  than  4  elements  of  a  data  set  are  to  be  changed, 
one  or  more  continuation  cards  of  type  CHPRM3  must  follow  a  CHPRM2  card. 
The  last  CHPRM2  card  In  the  deck  must  have  ***END  in  CC7-CC12.  The  type  of 
change  to  be  performed  is  specified  on  each  CHPRM2  card  with  the  following 
codes: 

CHGEL  -  change  one  element  (add  the  given  value  to  the  existing  value) 
SETEL  -  set  one  element  (see  the  value  to  the  given  value) 

SETSET  -  set  the  values  of  a  set  of  attributes 

ADDSET  -  add  the  set  of  attributes  to  the  model 

RELSET  -  release  a  set  of  attributes  from  the  model 

MITEL  -  multiply  the  value  of  one  element  by  the  given  value. 

A  deck  of  CHPRM  cards  will  be  read  whenever  subnode  5  of  node  ZINIT  is 
executed  by  an  exogenous  event  card  in  the  DATAN  deck.  The  actual  changes 
will  occur  at  that  time. 

10.  SCHEDULING  NETWORK  ATTACKS 

Attacks  on  links  and  terminals  in  the  transportation  network  may 
be  scheduled  exogenously  at  any  time.  One  card  is  used  in  the  ATACK  deck 
for  each  sortie  or  attack  on  a  single  transportation  element.  The  card 
specifies  the  time  of  the  attack  and  enables  the  user  to  change  any  of  the 
characteristics  of  the  link  or  terminal  prior  to  the  attack.  The  model 
then  calculates  the  effect  of  the  attack,  reduces  the  capacity,  and  sched¬ 
ules  a  rebuild  event  to  restore  the  existing  capacity.  The  format  of  ATACK 
cards  is  specified  in  Table  IV- 1 4 .  A  deck  of  ATACK  cards  will  be  read 
whenever  subnode  number  4  of  node  ZINIT  is  executed  by  an  exogenous  event 
card  in  the  DATAN  deck.  Attacks  to  links  and  terminals  may  be  intermixed 
in  the  ATTACK  deck.  Links  may  be  identified  by  their  number  or  by  their 
two  end  terminals.  The  former  should  be  used  if  there  is  more  than  one 
link  between  the  same  two  terminals  to  insure  that  the  proper  link  is 
attacked. 
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TABLE  TV- 13.  CHPRM  DATA  CARD  FORMATS 


DECK  OF  CHPRM  TO 

CHANGE  PERMAT  DATASETS  - 

CHPRM1  CARD  - 

CC  1-CC  6 

A6 

ENTER  CHPRM! 

CC  7-CC12 

A6 

OPTIONAL  NAME  FOR  THIS  CHANGE  SET 

CC13-CC14 

12 

NON-FATAL  SWITCH  (O-ERRORS  ARE  rATAL,  1- INPUT 
ERRORS  ARE  FLAGGED  ONLY) 

CHPRM2  CARD  - 

CC  1-CC  6 

A6 

ENTER  CHPRM2 

CC  7-CC12 

A6 

TYPE  OF  CHANGE  -  CHGEL,  SETEL,  SETSET,  ADDSET, 
RELSET  OR  MLTEL.  (***END  FOR  LAST  CARD) 

CC13-CC17 

A5 

NAME  OF  NODE  DATASET  IS  ASSOCIATED  WITH  OR 
**ALL 

CC18-CC23 

A6 

PERMAT  RESOURCE  FUNCTION  NAME  (E.G. ,  SUPAR, 
SICOM) 

CC24-CC33 

no 

RESOURCE  IDENTIFIER  (E.G. ,  ITEM  NUMBER) 

CC34-CC37 

A4 

FUNCTION  TYPE  (E.G. ,  SNOD,  SN01 ,  MNOD) 

ATTRIBUTE  NUMBER  OF  NUMBER  OF  ATTRIBUTES 

CC38-CC40 

13 

CC41-CC50 

FI 0.0  SINGLE  VALUE  TO  BE  USED  OR  FIRST  ATTRIBUTE 

(FOLLOWING  ONLY  USED  FOR  ADDSET  AND  SETSET) 

CC51-CC60 

F10.0 

SECOND  ATTRIBUTE 

CC61-CC70 

F10.0 

THIRD  ATTRIBUTE 

CC71-CC80 

F10.0 

FOURTH  ATTRIBUTE 

CHPRM3  CARD  -  ONLY  USED  FOR  ADDSET  OR  SETSET  WITH  MORE  THAN  4,  11,  OR  18 
ATTRIBUTES. 

CC  1-CC  6 

A6 

ENTER  CHPRM3 

CC  7-CC10 

4X 

NOT  USED 

CC11-CC20 

F10.0 

FIFTH,  TWELFTH,  OR  NINETEENTH  ATTRIBUTE 

CC21-CC30 

F10.0 

SIXTH,  THIRTEENTH,  OR  TWENTIETH  ATTRIBUTE 

CC31-CC40 

F10.0 

SEVENTH  OR  FOURTEENTH  ATTRIBUTE 

CC41-CC50 

F10.0 

EIGHTH  OR  FIFTEENTH  ATTRIBUTE 

CC51-CC60 

F10.0 

NINTH  OR  SIXTEENTH  ATTRIBUTE 

CC61-CC70 

F10.0 

TENTH  OR  SEVENTEENTH  ATTRIBUTE 

CC71-CC80 

F10.0 

ELEVENTH  OR  EIGHTEENTH  ATTRIBUTE 

LAST  CARD  IN  DECK  IS  A  CHPRM2 

CARD  WITH  ***END  IN  CC  7-CC12. 

FOR  A  VACUOUS  DECK,  THE  ***END  CARD  MAY  BE  A  CHPRM1  CARD. 
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rABLE  IV- 14.  ATACK  DATA  CARD  FORMATS 


CARDS  TO 

ATTACK  TRANSPORTATION  NETWORK  - 

CC1 

- 

CC5 

A5 

CARD  NAME  (ATACK) 

CC6 

- 

CC7 

12 

PRIMARY  CARD  -  ENTER  1 

CC8 

- 

CCIO 

3X 

BLANK 

CC11 

- 

CC20 

Fi  0. 0 

TIME  OF  ATTACK 

CC21 

- 

CC25 

15 

TERMINAL  NUMBER  OR  0  IF  LINK  NO.  IN  CC26-30 

CC26 

- 

CC30 

15 

TERMINAL  NUMBER  OR  LINK  NUMBER  FOR  LINK 

CHANGE  OR  0  FOR  TERMINAL  CHANGE 

CC31 

- 

CC40 

no 

TYPE  OF  CHANGE  REQUESTED  -  3,  ATTACK 

CC41 

- 

CC50 

F10.0 

NEW  RATE  OF  TRAVEL  ON  LINK 

CC51 

- 

CC60 

F10.0 

NEW  CAPACITY  OF  LINK/TERMINAL 

CC61 

- 

CC70 

F10.0 

NEW  PROBABILITY  OF  DESTRUCTION 

CC71 

- 

CC80 

F10.0 

NEW  TIME  TO  REBUILD 

IF  LENGTH 

OF  LINK 

IS  TO  BE  CHANGED,  INCLUDE  A  SECOND  CARD  - 

CC1 

- 

CC5 

A5 

CARD  NAME  (ATACK) 

CC6 

- 

CC7 

12 

CONTINUATION  CARD  -  ENTER  2  j 

CC8 

- 

CCIO 

3X 

BLANK  i 

ecu 

CC20 

F10.0 

NEW  LENGTH  OF  LINK 

END  CARD 

CC1 

- 

CC5 

A5 

CARD  NAME  (ATACK) 

CC6 

- 

CC7 

12 

ENTER  0 

CC8 

CC80 

73X 

BLANK 

IF  RATE, 

CAPACITY, 

PROB.  DESTRUC. ,  OR  TIME  TO  REBUILD  ARE  NOT  TO  BE 

CHANGED  - 

- 

ENTER  A 

VALUE  OF  - 

1.  THE  OLD  VALUE  FOR  PROBABILITY  OF 

DESTRUCTION 

WILL  BE  USED  FOR 

THIS  ATTACK.  OTHER  NEW  VALUES  (RATE, 

CAPACITY, 

, 

.  . )  WILL  BE  USED 

AS  THE  VALUE  THAT  THE  LINK/TERM  IS 

RESULT  TO 
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I.  SCHEDULING  SUPPLY  POINT  ATTACKS 


Attacks  on  intermediate  stockage  points  may  be  scheduled  exogen¬ 
ously  at  any  time.  One  card  is  used  in  an  ATSUP  deck  for  each  attack  on  a 
supply  point.  All  classes  of  material  or  specific  classes  may  be  destroyed 
as  specified  on  the  ATSUP  card.  The  card  specifies  the  time  of  the  attack, 
and  the  probability  of  destruction.  The  model  then  calculates  the  effect 
of  the  attack,  reduces  the  balance  on  hand,  and  orders  the  materiel 
destroyed  to  replenish  the  inventory  levels.  The  format  of  ATSUP  cards  is 
specified  in  Table  IV-15.  A  deck  of  ATSUP  cards  will  be  read  whenever 
subnode  number  10  of  node  ZINIT  is  executed  by  an  exogenous  event  card  in 
the  0 ATAN  deck.  Supply  points  are  identified  on  the  ATSUP  cards  by  their 
node  number  in  the  LOGATAK  model  description.  These  numbers  are  shown  in 
Table  IV-15. 

12.  SCHEDULING  COMMUNICATIONS  JAMMING 


Jamming  of  information  about  the  condition  of  the  transportation 
network  may  be  scheduled  exogenously  at  any  time.  One  card  is  used  in  a 
CCCU8  deck  to  initiate  jamming  of  information  for  a  link  in  the  network. 
Jamming  may  be  scheduled  by  the  model  to  stop  after  a  given  period  of  time 
or  it  may  be  turned  off  exogenously  by  another  CCCUB  card.  Information 
about  the  link  capacity  and  the  traffic  on  the  link  is  denies  to  the  trans¬ 
portation  routing  logic  while  the  communications  jammed.  The  format  of 
CCCUB  cards  is  shown  in  Table  IV-16.  A  deck  of  CCCUB  cards  will  be  read 
whenever  subnode  number  12  of  node  ZINIT  executed  by  an  exogenous  event 
card  in  the  OATAN  deck.  Links  are  identified  by  two  end  terminal  numbers 
or  the  link  number  on  the  CCCUB  card. 

13.  RESTART  INPUT  DECK 


The  major  input  to  a  restart  run  is  a  Restart  File  containing  the 
status  of  the  model  saved  at  some  point  during  an  earlier  run.  The  model 
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TABLE  IV- 15.  ATSUP  DATA  CARD  FORMATS 


CARDS  TO 

ATTACK  SUPPLY  INVENTORIES  - 

CC1 

-  CC5 

A5 

CARO  NAME  (ATSUP) 

CC6 

-  CC7 

12 

PRIMARY  CARD  -  ENTER  1 

CC8 

-  CCIO 

3X 

BLANK 

CC11 

-  CC20 

F10.0 

TIME  OF  ATTACK 

CC21 

-  CC30 

F10.0 

NUMBER  OF  NODE  ATTACKED* 

CC31 

-  CC40 

F10.0 

NUMBER  OF  PARAMETER  SLOT  OF  ATSUP  TO 
SCHEDULE  REPLENISHMENT** 

CC41 

-  CC50 

F10.0 

PROBABILITY  OF  DESTRUCTION-OR-  NEGATIVE 

CC51 

-  CC60 

F10.0 

SUPPLY  ITEM/CLASS  NUMBER-OR-ZERO  FOR  ALl 
ITEMS/CLASSES 

CC61 

-  CC80 

20X 

BLANK 

END  CARD 

CC1 

-  CC5 

A5 

CARD  NAME  (ATSUP) 

CC6 

-  CC7 

12 

END  CARD  -  ENTER  0 

CC8 

-  CC80 

73X 

BLANK 

* 

ASBOl  - 

6 

**  ASBOl  -  1 

ASB02  - 

7 

ASB02  -  2 

ASB03  - 

8 

ASB03  -  3 

ASB04  - 

9 

ASB04  -  4 

ASB05  - 

10 

ASB05  -  5 

'ABLE  IV- 16.  CCCUB  DATA  CARD  FORMATS 


CARDS  TO 

JAM  COMMUNICATIONS 

FROM  A  LINK  - 

CC1 

- 

CC5 

A5 

CARD  NAME  (CCCUB) 

CC6 

- 

CC7 

12 

PRIMARY  CARD  -  ENTER  1 

CC8 

- 

CCIO 

3X 

BLANK 

CC11 

- 

CC20 

FI  0.  0 

TIME  OF  CHANGE  IN  COUNTER  C-CUBE  ACTIVITY 

CC21 

- 

CC25 

15 

TERMINAL  NUMBER  OR  0  IF  LINK  NO.  IN  CC26-30 

CC26 

- 

CC30 

15 

TERMINAL  NUMBER  OR  LINK  NUMBER  IF  0  IN 

CC21-CC25 

CC31 

- 

CC40 

no 

KEY  TO  EVENT  TYPE 

(0  -  BEGIN  A  JAM 

1  -  END  A  JAM) 

CC41 

- 

CC50 

F10.0 

PROBABILITY  OF  A  SUCCESSFUL  JAM  (.6=60) 

PERCENT  CHANCE  OF  A  JAM) 

CC51 

- 

CC60 

F10.0 

LENGTH  OF  JAM 

(.GE.O  -  TIME  VALUE. 

. LT. 0  *  NEGATIVE  INDEX 

TO  PARAM  DISTRIBUTION) 

CC61 

CC80 

20X 

BLANK 

END  CARD 

CC1 

- 

CC5 

A5 

CARD  NAME  (CCCUB) 

CC6 

- 

CC7 

12 

END  CARD  -  ENTER  0 

CC8 

CC80 

73X 

BLANK 

can  be  restarted  at  that  point  in  simulation  time  and  continued  for  an 
arbitrary  period  of  time.  In  addition  to  the  Restart  File,  the  mode! 

requires  a  minimum  of  four  input  cards.  Additional  cards  to  schedule 
exogenous  events  after  the  restart  time  may  be  included  optionally.  The 

user  is  remined  that  all  events  in  the  time  file  on  the  Restart  File  are 
waiting  to  occur  and  should  not  be  reentered  in  card  form.  Figure  IV-4 
shows  the  card  deck,  setup  ror  a  restart  run.  The  format  for  the  LOGATAK 

card  is  shown  in  Table  IV- 17.  The  format  for  the  Restart  File  Identifica¬ 
tion  card  is  shown  in  Table  IV- 18.  The  restart  run  can  proceed  only  if  the 
identifiers  on  this  card  match  those  read  from  the  header  record  of  the 
Restart  File.  For  reference,  when  a  Restart  File  is  initially  created,  a 
notice  is  written  which  includes  the  format  and  content  of  the  restart  file 
identification  card  which  will  match  the  header  record  on  the  file.  The 
third  card  contains  the  amount  of  additional  time  to  be  simulated  and  the 
warmup  interval.  This  card  is  described  in  Table  IV- 1 9.  The  fourth  and 
last  card  of  the  minimum  restart  data  deck  is  a  card  with  a  zero  in 

column  8  representing  the  end  of  the  exogenous  events  subdeck. 

If  exogenous  events  are  to  be  read  from  cards  by  a  restart  run, 
they  are  included  between  the  third  and  fourth  cards  in  the  four-card  deck 
just  outlined.  Their  format  is  that  given  in  Table  IV- 1 .  Note  that  regard¬ 
less  of  whether  exogenous  events  are  included,  the  initial  card  of  this 
subdeck  as  described  in  Table  IV- 1  is  not  desirable  in  a  restart  run  since 
its  purpose  -  to  trigger  initialization  of  the  event  filing  array  -  is 
antithetical  to  the  purpose  of  a  restart  run,  namely  to  start  with  the 
files  of  the  model  at  more  realistic  states  than  the  empty  one  used  when 
starting  from  cards. 

Figure  IV-4  also  shows  optional  subdecks  of  change  cards  which 
may  be  read  by  the  model  in  the  order  and  at  the  times  specified  by  exogen¬ 
ous  event  cards  or  existing  events  in  the  time  file.  These  decks  have  been 
previously  described  in  this  chapter. 
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TABLE  IV- 17.  LOGATAK  CARD  FORMAT  FOR  RESTART 


FORTRAN 

COLUMN 

FORMAT 

DESCRIPTION 

1-10 

10X 

ENTER  "LOGATAK"  IN  COLS  1-6 

11-20 

FT 0.  0 

CENTRAL  PROCESSOR  TIME  LIMIT  IN  SECONDS  - 

CONTROL  IS  GIVEN  TO  THE  END-OF-RUN  REPORTING 

AND  EXIT  SEQUENCE  IF  THE  ELAPSED  CENTRAL 

PROCESSOR  TIME  SINCE  THE  RESTART  RUN  BEGAN 

EXCEEDS  THIS  LIMIT 

21-30 


F10.0 


RESTART  SWITCH,  SET  TO  1. 


TABLE  IV- 18.  RESTART  FILE  IDENTIFICATION  CARD  FORMAT 


FORTRAN 

COLUMN 

FORMAT 

DESCRIPTION 

1-6 

A6 

"RESTART,"  CARD 

7-8 

2X 

IGNORED 

9-20 

2A6 

MODEL  NAME 

21-22 

2X 

IGNORED 

23-40 

3A6 

RUN  NAME 

41-42 

2X 

IGNORED 

43-44 

12 

MONTH 

45-46 

12 

DAY 

47-50 

14 

YEAR 

51 

IX 

IGNORED 

52-61 

F10.3 

SIMULATON  TIME  , 

WRITTEN 

62 

IX 

IGNORED 

63-66 

14 

PROJECT  NUMBER 

67-68 

2X 

IGNORED 

69-80 

2A6 

ANALYST'S  NAME 

14.  CPC  CONTROL  CAROS 

The  source  code  for  the  LOGATAK  model  is  maintained  as  a  CDC 
UPOATE  file  on  tape.  Changes  are  made  to  the  code  utilizing  the  UPDATE 
capability  and  the  model  is  loaded  from  a  binary  version  of  the  code  stored 
on  the  same  taoe.  To  save  reloading  time  for  each  run,  an  absolute  loaa  is 
stored  on  a  disk  file  and  is  used  for  each  model  run.  The  control  caras  to 
update  the  code,  load  the  updated  binary  routines,  and  save  an  aDsolute 
load  file  are  shown  in  Figure  IV-5. 

The  control  cards  for  a  standard  model  run  from  a  cold  start  are 
shown  in  Figure  IV-6.  A  Restart  File  is  created  if  requested  in  the  model 
on  file  TAPE3,  and  this  file  can  be  catalogued  to  a  permanent  disc  file  at 
the  end  of  the  run.  The  model  input  data  can  be  read  from  cards  or  from  an 
UPDATE  data  file.  Both  options  are  shown  in  Figure  IV-6. 

The  control  cards  for  a  restart  model  run  are  shown  in 
Figure  IV-7.  In  this  sequence,  a  restart  file  at  15  days  was  used  to  start 
the  run  and  a  new  restart  file  was  created  at  30  days.  The  CATALOG  after 
the  exit  card  is  insurance  to  save  a  restart  file  if  the  model  abnormally 
ends  any  time  after  the  save  run. 
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REQUEST,  LGK,  VSN  =  1111,  MT,  NORING. 
COPYBF  (LGK,  OLOBIN) 

UPDATE  (P  =  LGK,  N,  R  =  C) 

RUN  (S,,,  COMPILE,,,  10000) 

REWIND,  LGO. 

REWIND,  OLDBIN 

COPYL  (OLDBIN,  LGO,  NEWBIN) 

REWIND,  NEWBIN. 

REQUEST,  MAW,  *PF. 

LOAD  (NEWBIN) 

NOGO. 

CATALOG  (MAW,  LGKABS ,  ID  =  LGKAV) 

Figure  IV-5.  Update  and  Load  Model  Control  Cards 
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INPUT  DATA  ON  CARDS 


ATTACH  (MAW,  LGKABS,  ID  =  LGKAV) 
REQUEST,  TAPE3,  *PF. 

MAW,  LC  =  TOOOOO. 

CATALOG  (TAPE3,  RESTART15,  ID  =  LGKAV) 
EXIT. 

CATALOG  (TAPE3,  RESTART! 5,  ID  =  LGKAV) 


INPUT  DATA  ON  UPDATE  FILE 


ATTACH  (OLDPL,  LGKDATA,  ID  =  LGKAV) 
UPDATE  (P,  C  =  TAPES,  D,  F) 

ATTACH  (MAW,  LGKABS,  ID  =  LGKAV) 
REQUEST,  TAPE 3 ,  *PF. 

MAW,  LC  =  100000,  TAPES. 

CATALOG  (TAPE3,  RESTART15,  ID  =  LGKAV) 


Figure  IV-6.  Control  Cards  to  Execute  the  Model  and  Save  the 
Restart  File 
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CHAPTER  V 
LOGATAK  REPORTS 


1.  GENERAL  DESCRIPTION 

The  LOGATAK  model  produces  a  set  of  reports  that  covers  the 
supply  and  transportation  activities  in  the  model.  A  standard  set  of 
reports  is  produced  when  a  run  is  terminated  normally.  If  a  model  run  is 
terminated  abnormally,  due  to  some  input  data  erros,  array  overflows,  or 
central  processor  time  limit  for  example,  the  standard  set  of  reports  is 
also  produced.  However  certain  errors,  such  as  illegal  data  in  a  card 
field,  are  nonrecoverable  and  the  output  reports  cannot  be  produced.  In 
addition  to  the  reports  at  the  end  of  a  run,  interim  reports  can  be 
requested  at  any  time  during  the  run  by  executing  subnode  8  of  node  ZINIT 
for  supply  reports  and  subnode  9  of  node  ZINIT  for  transportation  reports. 
These  events  are  scheduled  as  type  8  exogenous  events  (see  Chapter  IV. 2.). 

In  addition  to  the  standard  reports,  the  model  produces  a  limited 
report  when  a  SAVRUN  for  restart  file  is  requested,  so  that  the  user  is 
aware  of  the  status  saved  on  the  restart  file.  This  report  is  not  produce  * 
if  a  SAVRUN  file  is  requested  at  the  end  of  a  run,  that  is  if  TNOW  =  TFIN, 
since  the  standard  report  is  available. 

Optional  output,  in  the  form  of  an  event  by  event  trace,  is 
available  throughout  the  model  run  for  verification  of  the  model  activi¬ 
ties.  Each  of  the  report  types  is  described  in  a  section  in  this  chapter 
with  sample  pages  shown. 

2.  FILES  STATUS 


The  first  report  produced  designates  the  current  status  of  dis¬ 
tribution  parameters  and  file  contents.  The  files  in  the  LOGATAK  model  are 
those  which  store  all  events  waiting  to  occur  in  chronological  order, 
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arrival  queues  at  terminals,  departure  queues  at  terminals  and  a  split 
shipment  working  file.  The  time  file  is  always  numoer  1  and  if  shipments 

need  to  be  split  into  smaller  shipments,  the  working  file  is  number  2.  The 

remaining  files  are  assigned  as  needed.  The  numerical  assignment  is  given 
in  the  transportation  terminal  characteristics  report.  These  transporta¬ 
tion  queues  can  be  scanned  to  verify  what  the  average  and  maximum  size  is 
and  what  shipments  are  currently  in  the  queues.  The  attribute  definitions 
for  the  events  in  the  queues  and  the  time  file  are  given  in  Tables  V- 1  and 

V-2.  A  sample  of  the  Random  Variables  Parameters  report  is  shown  in  Fig¬ 

ure  V-l.  The  columns  contain  the  values  defined  in  Table  IV-9.  A  sample 
of  the  File  Printout  with  5  files  defined  is  shown  in  Figure  V-2. 

3.  REPORTS  FOR  SUPPLY  NODES 


Supply  node  reports  are  produced  at  the  end  of  a  model  run  and 
whenever  subnode  8  of  node  ZINIT  is  executed. 

3. 1  Demand  Generation  Nodes  Report 

The  status  of  each  demand  generation  node  (DSB01  to  DSB20)  that 
is  active  in  the  model  is  printed  out  for  each  item  or  class  of  supply 
ordered.  Figure  V-3  shows  a  sample  page  of  this  report.  Statistics  are 
shown  for  orders  generated  and  orders  received.  In  this  sample  for  DSB06, 
supply  class  10,  ten  orders  have  been  generated  for  1,130  metric  tons.  The 
average  order  size  was  113  tons  with  the  smallest  being  113  and  the  largest 
113.  The  time  weighted  average  quantity  due  in  from  supply  was  31.17  tons 
and  the  due  in  level  was  never  greater  than  226  tons.  The  average  duration 
of  due  ins  or  order  and  ship  time  was  .423  days  with  the  slowest  shipment 
requiring  .872  days.  To  this  point  in  simulated  time,  9  shipments  have 
been  received  with  a  total  of  1,017  tons.  All  of  the  shipments  ranged  were 
113  tons  each  in  size. 

3.2  Intermediate  Supply  Nodes  Report 

The  stock  status  and  demand  satisfaction  are  reported  for  each 
intermediate  supply  node  (ASB01  to  ASB05)  which  is  active.  Figure  V-4 
shows  a  sample  report  for  2  ASB  nodes.  The  serviceable  balance  on  hand  for 


90 


TABLE  '/-I.  TRANSPORTATION  SHIPMENT  ATTRIBUTES 


ATTRIBUTE 

DESCRIPTION 

1 

TIME  OF  OCCURRENCE 

n 

C 

CURRENT  LOCATION  TERMINAL  +  PAKTRM  *  IMMEDIATE 
DESTINATION  TERMINAL 

FINAL  DESTINATION  TERMINAL  +  1000.  *  POINTER  TO 
SHIPMENT  REQUESTOR 

4 

DEMANO  STATUS  +  1000.  *  ITEM/CLASS  IDENTIFIER 

5 

NUMBER  OF  ITEMS/UNITS  OF  MATERIAL  IN  SHIPMENT 

6 

PRIORITY 

7 

UP  TO  FOUR  LINK  NUMBERS  OF  SHIPMENT  ROUTING, 
PACKED  BY  FACTOR  OF  PAKLNK 

8 

REQUIRED  DELIVERY  DATE 

9 

ORDER  NUMBER 

10 

TIME  THAT  ORDER  ORIGINATED 

11 

WEIGHT  OF  THE  SHIPMENT 
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TABLE  V- 2.  C 


ATACK,  REBUILD  EVENT  ATTRIBUTES 


ATTRIBUTE 

DESCRIPTION 

1 

TIME  OF  OCCURRENCE 

2 

LINK  NUMBER  IF  LESS  THAN  IOOOOO 

TERMINAL  NUMBER  IF  FIRST  5  DIGITS  ARE  0 

LINK  DESIGNATION  BY  TERMINAL  END  POINTS 

OTHERWISE  (TERMINAL  +  100000  *  TERMINAL) 

3 

TYPE  OF  ACTION 

-1  DEACTIVATE 

0  ACTIVATE 
+1  ACTIVATE 

2  REBUILD 

3  ATTACK 

4 

NEW  RATE  OF  TRAVEL  ON  LINK 

5 

NEW  CAPACITY  OF  LINK/TERMINAL 

6 

PROBABILITY  OF  DESTRUCTION 

7 

TIME  TO  REBUILD 

8 

NEW  LENGTH  OF  LINK 
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Figure  V-l  .  Random  Variables  Parameters  Sample  Report 


AO-A1O0  736  BOM  CORP  MCLEAN  VA  F/©  y^,-. 

A  USER’S  GUIDE  FOR  LOGATAK.  A  SIMULATION  MODEL  TO  ANALYZE  LOftlS— FT'  '  .. 
APR  01  E  J  BITINASr  W  F  LYNCH  DNAOOI-79-C-0086 

UNCLASSIFIED  BDM/W-81-079-TR  DNA-6505H  NL 


Figure  V-2.  File  Contents  Sample  Report 
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Figure  V-3.  Demand  Generation  Nodes  Sample  Report 


Figure  V-4.  Intermediate  Supply  Node  Sample  Report 


ASB01,  item  !0,  ranged  from  a  low  of  865  tons  to  a  hign  of  2.323  tons.  The 
node  received  10  demands  for  2,430  tons  and  filled  10  of  those  demands  for 
2,430  tons.  The  percent  of  demands  filled  was  100%. 

4.  TRANSPORTATION  SYSTEM  REPORT 


The  transportation  system  report  consists  of  five  different  sub¬ 
reports.  First  the  current  status  of  the  network  is  printed  out  with  all 
links  specified  by  their  end  terminals  and  their  characteristics.  The 
column  labeled  CAPACITY  is  the  maximum  number  of  metric  tons  that  can  be 
placed  on  the  link  during  any  given  interval  of  time  equal  to  the  travel 
time  across  the  link.  The  capacity  per  day  of  the  link  is  also  shown.  A 
sample  page  of  this  report  is  shown  in  Figure  V-5.  The  next  section  of  the 
report  prints  the  current  characteristics  of  the  terminals  in  the  network 
and  any  queue  assignments  that  have  been  made.  A  sample  page  of  this 
report  is  shown  in  Figure  V-6. 

The  workloads  measured  at  each  terminal  that  was  utilized  in  the 
network  are  printed  in  the  next  section  of  the  report,  as  shown  in  Fig¬ 
ure  V-7.  The  average  capacity  and  average  number  of  metric  tons  in  the 
terminal  is  shown.  The  total  number  of  metric  tons  passing  through  the 
terminal  to  this  point  is  shown.  Finally  the  average  size  of  arrival  and 
departure  queues,  if  any,  are  shown.  The  link  workloads  are  presented  in  a 
similar  fashion  as  shown  in  Figure  V-8.  The  flow  pattern  experienced  in  a 
network  can  be  readily  visualized  when  the  tonnage  over  each  link  is  trans¬ 
ferred  to  a  map. 

The  final  workloads  report  (Figure  V-9)  is  presented  by  mode  of 
travel,  reporting  the  metric  ton  kilometer  utilization  for  each  mode.  The 
most  common  definition  of  mode  codes  is  as  follows: 

1  -  Air 

2  -  Sea 

3  -  Rail 

4  -  Highway 

5  -  Inland  Waterway 

6  -  Transshipment 
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Figure  V-5,  Sample  Network  Link  Report 


Figure  V-6.  Sample  Network  Terminal  Report 


nom  — •  •  *Mursr.vrnr_ bom  co»h 

DATE •  0/  2/  2219 
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Figure  V-7.  Sample  Terminal  Workloads  Report 


Figure  V-8.  Sample  Link  Workloads  Report 


5. 


PERMANENT  ATTRIBUTES  REPORT 


At  the  end  of  the  run,  all  supply  parameters  stored  in  the  array 
PERMAT  are  printed  out  for  each  supply  node.  These  attributes  were  definea 
in  Tables  IV-6,  IV-7,  and  IV-8.  A  sample  page  for  node  OSBOl  is  shown  in 
Figure  V- 1 0 .  This  node  handles  eight  different  supply  classes.  2.  3,  4,  5. 
6,  7,  10  and  11.  For  statistical  indices  that  have  been  utilized,  the 
position  in  the  statistics  data  storage  arrays  is  packed  in  with  the  type 
of  statistic.  For  example,  attribute  8  of  SIUN0D  for  class  2  shows  that 
this  is  a  COLCT  type  statistic  (3)  and  the  values  are  stored  in  location  22 
of  the  COLCT  arrays.  If  a  location  has  not  been  assigned,  i.e.,  there  is  a 
single  digit  as  input,  then  the  statistic  has  not  been  activated  yet. 

6.  SAVRUN  FOR  RESTART 


Whenever  a  SAVRUN  is  requested  to  create  a  file  for  later  restart¬ 
ing  of  the  model,  one  or  more  pages  is  printed  out.  The  first  page 
describes  the  identification  card  required  to  restart  the  model  utilizing 
this  file.  If  the  SAVRUN  is  not  at  the  end  of  the  model  run,  additional 
reports  similar  to  the  final  reports  are  produced  to  clearly  define  the 
conditions  in  the  model  at  that  point.  Only  the  last  SAVRUN  in  a  model  is 
available  on  the  file  since  the  previous  SAVRUN  is  overwritten.  Thus 
earlier  SAVRUNs  are  created  only  to  recover  from  premature  termination  of 
the  model . 

7.  EVENT  TRACE 


To  aid  in  debugging  the  model  and  checking  the  input  data  para¬ 
meters  and  model  logic,  an  event  trace  is  provided  in  the  model.  This 
trace  is  optional  and  may  be  turned  on  or  off  at  any  time  during  the  model 
run.  This  capability  is  controlled  through  exogenous  events  of  type  -2. 
The  trace  provides  an  event  by  event  history  of  all  activity  in  the  model 
durr  the  ti'-  the  trace  is  activated.  Each  module  that  is  used  during 
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Figure  V-10.  Sample  Permanent  Attributes  Report 


the  event  is  listed  Dy  name  to  aid  in  following  the  logical  path  followed. 
A  sample  page  from  a  trace  is  shown  in  Figure  >/— 1 1 .  This  page  snows  three 
complete  events  and  a  portion  of  two  others.  Each  event  starts  with  a  set 
of  attributes  removed  from  the  time  file.  The  attributes  have  been  defined 
in  Tables  V-l  and  V-2.  The  sample  shows  a  departure  event,  an  arrival 
event,  and  a  supply  delivery. 
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Figure  V-ll.  Sample  Page  from  Event  Trace 


CHAPTER  VI 
OPERATING  STRATEGY 


1.  GENERAL 

The  preceding  chapters  have  described  various  aspects  of  the 
LOGATAK  computer  model,  and  have  presented  detailed  instructions  describing 
how  to  operate  the  various  component  parts  of  the  model.  This  chapter  ties 
together  the  detailed  instructions  of  the  previous  chapters  and  presents  a 
number  of  observations  on  how  the  LOGATAK  model  can  be  operated  to  present 
the  most  useful  simulation  of  the  desired  problem.  The  suggestions  pre¬ 
sented  in  this  chapter  are  generally  grouped  around  building  the  scenario, 
gathering  the  required  data,  running  the  model,  and  analyzing  the  model 
results. 

If  one  paramount  observation  could  be  made  concerning  the  appli¬ 
cation  of  the  LOGATAK  model,  it  would  be  this:  the  number  of  simulation 
features  available  in  the  model  is  so  large  and  the  ability  of  the  data 
base  to  accept  information  is  so  great,  the  model  is  capable  of  overwhelm¬ 
ing  any  available  computer  capacity  or  program  budget.  Since  it  is  not 
technically  nor  financially  feasible  to  model  the  whole  world,  the  analyst 
must  necessarily  exert  censorship  on  the  building  of  his  model.  The 
scenario  must  be  a  test  of  the  desired  effects.  The  temptation  is  always 
great  to  include  every  factor  of  the  logistic  system  in  detail,  but  this 
temptation  rapidly  overwhelms  the  capability  of  the  computer. 

2.  SCENARIO 

In  designing  the  scenario  for  a  LOGATAK  run,  the  analyst  must 
first  determine  which  factors  are  significant  in  the  problem  he  is  study¬ 
ing,  and  which  factors  are  clearly  second  order  variables  which  will  have 
little  or  no  influence  on  the  final  answer.  On  the  face  of  it,  the  preced¬ 
ing  statement  tends  to  sound  like  a  pre- judgement  and  pre-determination  of 
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the  final  results  of  the  model  run.  but  such  need  not  be  the  case.  5ome 
careful  consideration  of  the  problem  before  the  model  is  built  will  usually 
indicate  which  effects  can  be  safely  suppressed.  If  the  problem  to  be 
considered  involves  a  short,  rapidly-moving  war.  factors  usually  associated 
with  long  term  attrition  such  as  higher  echelon  maintenance  activities, 
spare  part  stocks,  and  the  movement  of  logistic  supplies  far  behind  the 
battlefront  are  usually  of  little  significance  to  the  outcome.  On  the 
other  hand,  if  the  scenario  involves  a  slow  campaign  of  attrition,  factors 
involving  battlefield  mobility  of  fighting  units  are  of  little  consequence. 
Exceptions  exist  to  every  general  statement,  but  the  point  to  be  emphasized 
is  that  careful  forethought  will  clarify  the  issues  in  a  problem  and  safely 
enable  the  suppression  of  some  variables  as  second-order. 

The  scenario  must  be  carefully  constructed  to  be  realistic  and  to 
incorporate  the  desired  type  of  battlefield  and  logistic  operations.  Each 
national  military  establishment,  either  friendly  or  enemy,  has  individual 
features  of  its  operations  in  every  activity,  such  as  battlefield  tactics, 
doctrines  of  ammunition  expenditure,  doctrines  concerning  marching  order, 
and  doctrines  regulating  the  operation  of  its  logistic  system.  These 
factors  should  be  investigated  and  incorporated  into  the  scenario  so  that 
the  results  will  be  representative  of  the  operation  of  the  force  under 
consideration. 

An  important  factor  in  the  construction  of  a  scenario  is  to 
achieve  a  proper  proportion  between  the  total  size  of  the  operational 
battle  force  and  the  capability  of  the  existing  physical  features  of  the 
logistic  network,  such  as  terminals  and  transportation  links.  The  general 
nature  of  an  interdiction  attack  which  is  directed  primarily  against  fixed 
installations  rather  than  vehicles,  for  example,  is  an  initial  wearing-down 
of  the  "surplus  capacity"  of  the  logistic  network,  after  which  the  support 
to  the  battle  forces  begins  to  deteriorate.  For  any  given  part  of  the 
world,  it  can  readily  be  appreciated  that  the  existing  transportation 
network  is  more  than  enough  to  support  a  very  small  battlefield  force,  but 
insufficient  to  support  an  extremely  large  battlefield  force,  even  without 
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interdictive  attack.  The  absolute  size  of  the  battle  force  selected  for 
the  scenario  thus  becomes  an  important  factor  in  the  apparent  success  of 
any  interdiction  campaign,  without  consideration  of  the  nature  or  severity 
of  the  interdicti ve  attacks.  For  this  reason  special  care  must  be  taken  to 
size  the  supported  battle  force  realistically  in  terms  of  the  military 
campaign  envisaged.  If  it  is  thoughtlessly  chosen  either  excessively  large 
or  small,  the  results  of  the  simulation  will  be  inadvertently  biased. 

The  interdiction  plan  in  the  scenario  should  make  best  use  of 
weaknesses  in  the  logistic  support  structure.  Frequently  a  geographic 
weakness  can  be  found  in  the  form  of  a  "barrier  line,"  either  a  physical 
feature  such  as  a  river  or  mountain  chain,  or  a  weakness  in  the  man-made 
logistic  network,  or  a  combination  of  the  two  factors.  If  uncertainty 
exists  in  a  given  scenario  as  to  the  best  choice  of  logistic  barrier, 
different  strategies  of  attack  should  be  tried  in  separate  computer  runs  to 
observe  the  variation  in  results.  Such  preliminary  trials  can  be  very 
useful  in  improving  the  effectiveness  and  realism  of  the  interdiction 
attacks  chosen  in  the  scenario. 

3.  INPUT  DATA 


A  considerable  opportunity  exists  in  the  preparation  of  the  data 
base  to  eliminate  less  important  information  by  means  of  data  aggregation. 
In  preparing  the  data  base  for  a  highway  system,  for  example,  there  are 
usually  roads  which  are  so  small  and  poorly  made  that  their  freight  capa¬ 
city  is  insignificant  compared  to  better  roads  in  the  same  vicinity.  These 
secondary  roads  can  be  aggregated  to  form  theoretical  roads  whose  capacity 
and  rate  of  travel  simulates  the  combination  of  more  than  one  actual 
secondary  road.  A  suggested  set  of  guidelines  which  were  found  useful  in 
LOGATAK  runs  are  as  follows: 

(1)  A  data  base  element  is  subject  to  aggregation  if  it  is  not  a 
worthwhile  target  of  interdictive  attack. 

(2)  Only  elements  of  like  character  should  be  aggregated,  for  example 
a  country  road  should  not  be  aggregated  with  a  freeway. 
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(3)  The  aggregated  elements  should  serve  the  same  genera!  purpose, 
that  is,  if  they  are  roads  they  should  run  in  roughly  the  same 
direction  and  be  reasonably  close  together. 

Data  base  aggregation  enables  the  analyst  to  simulate  the  real 
world  to  a  level  of  quality  adequate  for  the  LQGATAK  simulation  while  at 
the  same  time  eliminating  a  great  deal  of  insignificant  information  before 
it  ever  gets  into  the  computer.  As  will  be  seen  later  in  Part  5  of  this 
chapter,  excessive  aggregation  of  the  data  base  which  distorts  the  final 
simulation  output  can  easily  be  reversed,  but  need  be  reversed  only  in  the 
areas  where  greater  detail  is  significant  to  the  particular  simulation. 
The  flexibility  in  the  data  base  provided  by  DAMSEL  thus  encourages  the 
analyst  to  aggregate  apparently  insignificant  information,  since  this 
aggregation  is  not  permanent. 

The  kill  probabilities  associated  with  logistic  strikes  should 
obviously  be  as  realistic  as  possible,  since  they  greatly  influence  whether 
a  particular  interdiction  attack  has  been  successful.  If  a  particular 
model  run  uses  stochastic  kill  probabi 1 ities,  the  analyst  should  take  care 
to  make  a  sufficient  nubmer  of  model  runs  to  evaluate  scatter  in  the  final 
results  which  stems  from  variation  in  the  stochastic  kill  probabilities. 
No  hard  and  fast  rules  can  be  made  concerning  the  number  of  times  a  run 
must  be  repeated  to  evaluate  stochastic  effects,  but  since  kill  probabili¬ 
ties  are  one  of  the  few  stochastic  processes  in  LOGATAK,  the  analyst  should 
be  alert  for  this  type  of  problem. 

It  is  important  to  have  accurate  estimates  of  rebuild  capability, 
both  the  time  it  takes  to  rebuild  a  target,  and  the  degree  of  restoration 
in  capacity  and  rate  of  travel.  Interdiction  is  essentially  a  race  between 
destruction  and  rebuild.  It  doesn't  make  for  a  balanced  study  to  put  a 
great  deal  of  effort  into  estimating  probabilities  of  kill  and  extent  of 
destruction,  and  then  to  input  hasty  rebuild  estimates.  The  model  will 
accept  rebuild  estimates  in  a  variety  of  ways.  First,  the  DAMSEL  data  base 
has  the  capability  to  store  standard  rebuild  times  and  capacities  for  each 
target  which  is  likely  to  be  attacked.  Second,  at  the  time  any  attack  is 
input  to  the  LOGATAK  model,  the  attack  card  may  contain  a  modified  value  of 
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rebuild  time  and  target  capacity  as  rebuilt.  Third,  even  if  rebuilt  target 
capacity  is  changed  by  che  attack  card,  a  subsequent  "change  net"  card  can 
be  input  to  the  computer  to  restore  the  target  capability  to  the  original 
values  or  any  other  values  desired.  Since  there  is  no  limit  to  the  number 
of  change  net  cards  which  may  be  input,  the  analyst  has  great  flexibility 
in  altering  th  capability  of  rebuilt  targets  as  a  function  of  time.  This 
model  capability  enables  the  analyst  to  tailor  target  rebuilding  to  match 
time- varying  estimates  of  rebuild  capability. 

4.  RUNNING  THE  MODEL 


The  first  point  to  be  made  concerning  the  building  of  a  LOGATAK 
simulation  is  that  the  analyst  should  not  expect  a  perfect  run  the  first 
time  through.  Network  problems  are  complex  and  there  are  many  interactions 
between  the  data  base,  input  assumptions  and  attack  strategies,  which 
sometimes  do  not  mesh  well  together.  As  difficulties  show  up,  the  analyst 
should  expect  to  perform  a  certain  amount  of  fine  tuning  to  the  model 
inputs  in  order  to  improve  realism  in  trouble  areas. 

The  use  of  the  save  run  (SAVRUN)  feature  in  LOGATAK  is  especially 
valuable  in  tuning  up  the  model.  The  liberal  use  of  the  save  run  feature 
produces  several  benefits  to  the  analyst: 

(1)  Save  run  permits  the  analyst  to  feel  his  way  through  the  simula¬ 
tion  run,  looking  at  intermediate  results  at  frequent  intervals 
to  see  if  trouble  is  building  up.  It  permits  interaction  between 
the  analyst  and  the  run  as  the  simulation  proceeds  and  enables 
the  analyst  to  terminate  a  run  which  is  not  going  well,  thus 
saving  computing  time. 

(2)  The  save  run  feature  permits  the  printing  of  ither  a  supply 
report,  a  transportation  report,  or  both,  at  any  point  in  the 
run,  depending  on  what  types  of  information  the  analyst  desires. 

(3)  The  save  run  feature  provides  comprehensive  pictures  of  the 
development  of  the  scenario  at  frequent  time  intervals,  rather 
than  relying  on  final  results  only.  These  intermediate  pictures 
not  only  aid  the  analyst  in  understanding  his  model,  but  are  also 
very  worthwhile  when  report  time  comes. 
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A  useful  feature  in  the  LOGATAK  mode]  during  the  early  running 
stage  is  the  ability  to  put  time  limits  on  the  runs.  This  feature  supple¬ 
ments  the  save  run  feature  to  save  wasted  computer  time  on  runs  which  have 
gone  bad  for  some  reason. 

A  useful  way  to  begin  the  validation  of  a  simulation  is  to  per¬ 
form  a  baseline  run,  that  is,  a  runthrough  of  the  scenario  with  no  inter¬ 
diction  attacks.  The  baseline  run  orovides  a  perspective  of  how  the 
logistic  system  performs  the  task  required  by  the  scenario  without  inter¬ 
ference.  For  example,  because  of  unusual  demands  or  a  weak  spot  in  the 
logistic  system,  significant  queues  may  form  even  without  interdiction.  A 
very  useful  tool  in  the  analysis  of  the  baseline  run  is  to  prepare  simple 
flow  charts  showing  the  traffic  through  each  link  and  terminal  in  the 
logistic  system  at  various  points  in  time.  These  simple  charts  raoidly 
disclose  the  existence  of  unusually  heavy  traffic  or  queues.  The  analyst 
should  be  especially  sensitive  to  these  points  of  heavy  traffic  because 
they  may  result  either  from  some  element  of  unrealism  inadvertently  placed 
in  the  model  (which  should  be  corrected),  or  they  may  point  up  a  deficiency 
in  the  real  logistic  network  which  can  be  exploited  by  an  interdictive 
attack.  A  "by  hand"  analysis  will  determine  whether  these  heavy  traffic 
locations  are  real  choke  points  or  whether  they  come  from  unrealism  in  the 
input  assumptions. 

As  indicated  in  Part  3,  variations  in  stochastic  kill  probabili¬ 
ties  will  sometimes  influence  the  results  obtained  from  model  runs  in 
peculiar  ways.  The  analyst  should  be  on  the  look-out  for  unusual  results 
of  this  type  which  do  not  reflect  long  term  realism. 

5.  ANALYZING  THE  MODEL  RESULTS 


In  reviewing  the  results  of  the  model  runs,  the  analyst  should 
keep  several  factors  in  mind.  In  a  model  as  complex  as  LOGATAK,  many  types 
and  variations  in  input  data  are  required,  and  some  types  of  input  data  are 
better  known  than  others.  If  uncertainty  exists  with  respect  to  certain 
classes  of  input  data  or  attack  strategies,  separate  runs  of  the  model  can 
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be  made  to  cover  the  spectrum  of  input  possibilities.  Under  the  controlled 
conditions  of  the  model,  these  sensitivity  studies  will  give  the  analyst  a 
good  feel  for  the  quantitative  effect  of  variation  caused  by  input  data 
uncertainty.  Depending  on  the  degree  of  effect  in  the  final  results,  the 
analyst  may  or  may  not  wish  to  expend  additional  effort  improving  the  input 
data.  One  especially  important  type  of  improvement  in  input  data  is  the 
potential  de-aggregation  of  transportation  network  data.  It  will  sometimes 
be  found  that  most  of  the  network  aggregation  is  appropriate  and  realistic, 
but  in  certain  localities,  special  cases  cause  an  unusually  heavy  traffic 
load,  and  greater  detail  is  desired  to  see  what  is  happening.  In  such 
areas  the  secondary  roads  can  be  de-aggregated,  more  detailed  data  can  be 
reentered  through  DAMSEL,  and  the  degree  of  realism  in  the  special  locality 
can  be  improved  without  the  necessity  to  rework  the  entire  transportation 
network  data  base. 

A  variety  of  different  attack  strategies  should  be  generally  be 
used  to  determine  which  strategies  appear  most  cost/effective  in  creating 
interdiction.  LOGATAK  is  very  helpful  in  developing  superior  interdiction 
strageties,  as  the  traffic  flows  generated  by  the  model  show  clearly  how 
the  logistic  net  responds  to  interdictive  damage,  and  "avenues  of  escape" 
can  be  successively  closed  off. 

One  of  the  important  benefits  of  interdictive  attack  is  the 
reduction  in  the  mobility  of  battle  forces,  as  well  as  the  more  usual 
reduction  in  level  of  supplies.  Many  battles  are  won  or  lost  by  the  degree 
of  mobility  in  the  battlefield  military  units,  because  a  unit  away  from  the 
main  action  is  often  of  no  more  value  than  a  unit  which  has  been  destroyed. 
In  many  scenarios,  the  movement  of  military  units  through  the  logistic 
support  area  competes  for  the  use  of  these  facilities  with  the  movement  of 
supplies,  and  unit  moves  must  be  accounted  for  in  the  model  as  they  are 
often  the  heaviest  user  of  logistic  network  capability. 

It  has  been  previously  mentioned  that  the  model  will,  from  time 
to  time,  produce  results  of  a  very  surprising  nature  to  the  analyst.  The 
analyst  should  be  especially  sensitive  to  these  situations,  because  the 
surprise  is  caused  either  by  a  serious  inconsistency  in  the  model  which 


/ 


produces  destructive  unrealism  in  the  simulation,  or  by  a  truly  novel 
effect  not  present  in  the  analyst's  previous  experience.  These  new  effects 
are  among  the  most  valuable  results  produced  by  the  exercise  of  the  LQGATAK 
model,  and  they  should  be  followed  ud  and  studied  carefully  as  potential 
new  improvements  in  interdiction. 
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CHAPTER  VII 
FORCE  MOVEMENT  OPTION 


1.  INTRODUCTION  AND  PURPOSE 

The  LOGATAK  model  has  been  developed  for  analyzing  logistics  networks 
before  and  after  interdictive  attack,  as  described  in  the  previous 
chapters.  Because  forces  moving  to  the  front  must  compete  with  logistical 
traffic  along  the  same  transportation  network,  the  LOGATAK  model  can  be 
used  to  investigate  mobilization  and  interdiction  of  reinforcements. 

The  Force  Movement  Option  to  LOGATAK  provides  the  user  with  the  abil¬ 
ity  to  move  units  according  to  their  organizational  order  of  march  from 
garrison  locations  in  rear  areas,  up  to  pre-commitment  locations.  Units 
are  provided  with  organic  bridging  and  the  ability  to  clear  obstacles 
(landslides,  mines)  and  perform  these  functions  on  an  as  need  basis.  To 
accommodate  these  requirements  some  additional  input  data  is  required. 
This  takes  the  form  of  the  division  organization,  the  division  movement, 
and  organic  bridging  capability. 

To  improve  the  interdiction  aspects  of  LOGATAK,  the  target  set  idea 
has  been  developed.  Targetable  entities  along  the  transportation  network 
are  grouped  into  target  sets.  A  number  of  attacks  are  performed  against  a 
set  at  once.  Sets  could  consist  of  rail  bridges,  marshalling  yards,  etc. 
Those  elements  of  a  set  already  destroyed  (and  not  yet  repaired)  will  not 
be  restruck  during  subsequent  attacks.  Targets  can  be  in  one  or  more  sets 
at  the  same  time. 

Additionally,  the  ability  to  attrit  units  and  create  obstacles  has 
also  been  included.  Off-road  movement  around  obstacles,  reconstitution  and 
wrecks  have  been  included  in  the  expanded  attack  module. 

Every  attempt  to  minimize  additional  computer  requirements  has  been 
made.  Much  of  the  new  data  has  been  woven  into  the  existing  logistics 
network  data  to  minimize  restructuring  of  the  model. 


INPUT  OATA  FOR  FORCE  MOVEMENT 


2. 1  Unit  Organizations 

2.1.1  Supply  Item  Common  Data 

The  smallest  indivisible  unit  to  be  represented  in  the  model  is 
considered  to  be  a  supply  item.  Identification  numbers  one  through  eight 
are  reserved  for  this  purpose.  The  SICOM  attributes  have  been  expanded  to 
include  attrition  effects  for  up  to  six  weapon  types  (Table  VII-1).  This 
attrition  is  expressed  as  a  percentage  of  a  full  strength  unit  destroyed 
per  weapon  application. 

2.1.2  Parent  Unit  Organization 

These  component  units  are  organized  into  parent  units  through  the 
use  of  the  ORGAN  data  card  (Table  VI 1-2) .  The  order  of  march  of  the  parent 
unit  is  represented  by  the  matrix  of  organization.  The  items  in  the  first 
set  will  move  first,  second  set  second,  etc.  Up  to  seven  sets  can  be 
represented. 

2.2  Parent  Unit  Movement 

To  ease  the  burden  of  data  preparation,  an  entire  parent  unit 
consisting  of  as  many  as  504  items  can  be  input  for  movement  through 
LOGATAK  using  only  one  data  card  (Table  VI 1-3 ) .  This  module  will  construct 
shipments  of  each  item,  assign  priorities,  and  begin  movement  through  the 
transportation  network.  The  LOGATAK  departure  time  may  differ  from  the 
actual  departure  time  to  include  movement  outside  of  the  area  of  interest. 

Movement  priority  is  used  by  LOGATAK  to  resolve  contention  on 
link  usage.  Lowest  numbers  move  first.  The  user  should  use  the  case  of 
two  units  attempting  to  cross  one  bridge  simultaneously  to  resolve  movement 
priority  problems. 

3.  INTERDICTION 


Expanded  interdiction  capabilities  have  been  included  in  the  force 
movement  option  of  LOGATAK.  Mines,  landslide  areas  and  attrition  of  of 
units  on  the  move  have  been  included,  as  well  as  targeteering,  intel¬ 
ligence,  weaponeering,  and  limited  strike  assets. 


TABLE  VII- 1.  SICOM  ATTRIBUTES  FORCE  MOVEMENT  OPTION 


SICOM  (ITEM)  - 

COMMON  SUPPLY  ITEM  DATA 

ONE  SET  FOR  EACH  UNIT  TYPE  (ITEM 
IDENTIFICATION  NUMBERS  1  THROUGH  3) 

USE  CARD  TYPE  INITP3 

ATTRIBUTE 

DESCRIPTION 

1 

WEIGHT  OF  UNIT 

4 

ITEM  TYPE  CODE  (1) 

5 

SOURCE  OF  ITEM  IDENTIFICATION 

NUMBER  (GENERALLY  THE  SAME  AS 

SICOM  ID  NUMBER) 

8 

STATISTICAL  INDICATOR  FOR  OVERALL 

WEAPON  EFFECT  (3) 

-9 

INDEX  TO  ATTRITION  DISTRIBUTION 

FOR  WEAPON  TYPE  1 

10 

STATISTICAL  INDICATOR  FOR  ATTACK 

EFFECTIVENESS  OF  WEAPON  TYPE  1  (3) 

11 

INDEX  TO  ATTRITION  DISTRIBUTION 

FOR  WEAPON  TYPE  2 

12 

STATISTICAL  INDICATOR  FOR  WEAPON 

TYPE  2  (3) 
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TABLE  VII-4.  PARENT  UNIT  ORGANIZATION  DATA  CARD  FORMAT 


COLUMN 

FORMAT 

DESCRIPTION 

1-5 

A5 

CARD  NAME  (ORGAN) 

6-7 

12 

SEQUENCE  NUMBER  (ENTER  1) 

8-10 

13 

UNITED  TYPE  IDENTIFICATION 

11-12 

2X 

13 

11 

NUMBER  OF  ITEM  1  UNITS 

14 

11 

ii  it  ii  2  11 

15 

11 

ii  ii  ii  ^  " 

16 

11 

n  ii  ii  ^  ii 

17 

11 

n  ii  ii  g  ii 

18 

11 

it  ii  i«  g  ii 

19 

11 

il  ii  ii  y  n 

20 

11 

ii  it  n  g  ii 

21-22 

2X 

23-30 

811 

REPEAT  CC1 3  -  CC20 

31-80 

5(811) 

REPEAT  21  -  30  AS  REQUIRED 
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FABLE  VI 1-3.  PARENT  UNIT  DIVISION  DATA  CARD  FORMAT 


COLUMN 

FORMAT 

DESCRIPTION 

1-5 

A5 

CARD  NAME  (DIVSN) 

6-7 

12 

PRIMARY  CARD  (ENTER  1) 

8-10 

3X 

11-20 

F10.0 

TIME  OF  DEPARTURE  IN  LOGATAK 

21-24 

4X 

25-27 

13 

ORIGIN  TERMINAL 

28-30 

13 

DESTINATION  TERMINAL 

31-40 

F10.0 

TYPE  OF  PARENT  UNIT 

1 

cn 

o 

F10.0 

ACTUAL  DEPARTURE  TIME 

51-60 

no 

UNIQUE  DIVISION  IDENTIFICATION 

NUMBER 

61-65 

5X 

66-68 

13 

PRIORITY 

69-80 

12X 

I 


3. 1  Target  Set  Concept 

Strikes  are  carried  out  against  target  sets.  At  present,  oniv 
links  and  terminals  are  included  in  a  set.  Links  and  terminals  are  grouped 
by  some  analyst-defined  rule,  and  strikes  are  carried  out  against  these 
sets.  This  helps  the  analyst  by  reducing  his  burden  on  input  preparation. 
Table  VII-4  describes  the  input  for  target  sets. 

3. 2  Basic  Repair  Groups 

Targets  are  repaired  in  two  ways:  automatically  some  time  after 
attack  (simulating  dedicated  repair  assets)  and  on  demand  (organic  engineer 
capability).  Mines  are  cleared  by  any  units  encountering  this  type  of 
obstacle.  Once  struck,  a  target  will  be  repaired  in  one  of  these  two  ways. 
Some  parameters  of  the  repair  must  be  addressed.  Table  VI 1-5  lists  the 
input  format  for  the  basic  repair  groups.  A  group  could  consist  of  pontoon 
bridges,  track  laying,  mine  clearing,  etc. 

3. 3  Attack  Execution 

Because  many  more  options  for  interdiction  have  been  added  to 
LOGATAK,  a  new  attack  module  has  been  developed,  with  a  wide  variety  c*' 
options  (Table  VI 1-6) . 

4.  OTHER  MODEL  ADDITIONS 


Additional  exogenous  events  have  been  added  to  reflect  the  force 
movement  option  (Table  VI 1-7) .  These  include  the  additional  input  data 
requirements  described  above,  and  additional  reporting  features. 

4. 1  Queue  Report 

A  list  of  all  queues  currently  (at  the  time  of  the  report)  in 
existence  are  organized  by  terminal  number,  and  the  members  of  the  queue. 

4.2  Target  Status  Report 

An  abbreviated  version  of  the  transportation  report,  dealing  only 
with  elements  of  the  network  that  are  included  in  target  sets. 

4.3  Attack  Effects  Report 

Upon  attacking  items  in  transit,  LOGATAK  keeps  statistics  on  the 
effect  of  each  type  weapon  on  the  attrition  of  the  item.  This  report  gives 
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TABLE  VI 1-4.  TARGET  SET  DATA  CARO  FORMAT 


COLUMN 

FORMAT 

DESCRIPTION 

1-5 

A5 

CARD  NAME  (ENTER  ROAST) 

6-7 

12 

CARD  NUMBER  (ENTER  1) 

8-10 

3X 

11-15 

15 

TARGET  SET  NUMBER  (MAX.  100) 

16-20 

5X 

21-25 

15 

TERMINAL  NUMBER,  LINK  END  POINT 

OR  ZERO 

26-30 

15 

LINK  NUMBER,  LINK  END  POINT  OR 

ZERO 

31-40 

F10.0 

TARGET  PROBABILITY  OF 

DESTRUCTION  (0.  TO  1.) 

41-50 

no 

BASIC  REPAIR  GROUP  IDENTIFICATION 

TYPE  (NEGATIVE  FOR  REBUILD  ON 

OEMAND ,  POSITIVE  FOR  AUTOMATIC 
REPAIR) 

51-60 

10X 

61-70 

F10.0 

LENGTH  OF  REPAIR  OR  INTERIM 

TERMINAL  CAPACITY 

71-78 

8X 

79-80 

F10.0 

TARGET  PRIORITY  WITHIN  SET 
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TABLE  V 1 1 - 5 .  BASIC  REPAIR  GROUP  DATA  CARO  FORMAT 


COLUMN 

FORMAT 

DESCRIPTION 

1-5 

A5 

CARD  NAME  (ENTER  RDBRG) 

6-7 

12 

CARD  NAME  (ENTER  1) 

8-10 

3X 

11-15 

15 

GROUP  TYPE  NUMBER 

16-20 

15 

MATERIAL  AVAILABILITY  DELAY 

DISTRIBUTION  INDEX 

21-30 

F10.0 

RATE  OF  TRAVEL 

31-40 

F10.0 

CAPACITY/DISTANCE 

41-50 

F10.0 

CONSTRUCTION  TIME 

DISTANCE/TIME 

51-60 

F10.0 

PROBABILITY  OF  DESTRUCTION 

(0.0  TO  1.0) 

61-80 

20X 

TABLE  VII-6.  ATTACK  TARGET  SET  DATA  CARD  FORMAT 


COLUMN 

FORMAT 

DESCRIPTION 

1-5 

A5 

CARD  NAME  (ENTER  ATSET) 

6-7 

12 

CARD  NUMBER  (ENTER  1) 

8-10 

3X 

11-20 

F10.0 

TIME  OF  ATTACK 

21-30 

F10.0 

TARGET  SET  NUMBER 

31-36 

16 

WEAPON  TYPE  NUMBER 

37 

11 

LINK  PRIORITY 

(0  -  AS  IN  TARGET  SET 

1  -  LINKS  IN  USE  ONLY 

2  -  LINKS  IN  USE  FIRST) 

38 

11 

ATTRITABLE  ITEM  TYPES 

(0  -  ALL 

1  -  ITEMS  1  THROUGH  8 

2  -  ITEMS  9  AND  ABOVE) 

39-40 

12 

TYPE  OF  ATTACK 
(0,1,3,4,7,8,10,11  -  LINKS, 

0,5  -  TERMINALS 

2.6.7.8.12  -  QUEUES 

6,7  -  UNITS  MOVING 

3,4,5  -  MINES 

10.11.12  -  NUCLEAR) 

41-46 

16 

MINIMUM  ATTACKABLE  QUEUE  SIZE 

47-50 

F4.0 

WEAPON  EFFECTIVENESS  (0.  TO  1.) 

51-55 

15 

MAXIMUM  NUMBER  OF  WEAPONS 

PER  TARGET 

23 


TABLE  VII-6.  ATTACK  TARGET  SET  QATA  CARD  FORMAT  (CONTINUED) 


COLUMN 

FORMAT 

DESCRIPTION 

56-60 

15 

TOTAL  NUMBER  OF  WEAPONS  FOR  THIS 

ATTACK 

61-70 

F10.0 

PROBABILITY  OF  DESTRUCTION 

MULTIPLIER  (NUCLEAR  STRIKE) 

OR  LENGTH  OF  MINE  FIELD 

71-80 

F10.0 

TIME  DELAY  (NUCLEAR  AND  MINES) 
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TABLE  VI I- 7.  ADDITIONAL  ZINIT  SUBNODES  WHICH  CAN  BE  SCHEDULED  EXOGENOUSLY 


SUBNOOE  NUMBER 

""i 

PURPOSE  j 

14 

i 

INTERIM  QUEUE  SUMMARY  REPORT 

15 

INTERIM  TARGET  SET  STATUS  REPORT 

16 

DIVSN- INPUT  PARENT  UNIT  MOVEMENT 

CARDS 

17 

ORGAN- INPUT  FORCE  ORGANIZATION 

18 

RDBRG- INPUT  BASIC  REPAIR  GROUP  DATA 

RDAST- INPUT  TARGET  SETS 

19 

ATSET- ATTACK  A  TARGET  SET 

20 

ATRPT-ATTACK  EFFECTIVENESS  REPORT 
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the  breakdown  of  the  effectiveness  of  aacn  weapon  on  each  item  and  an 
aggregate  for  all  weapons  on  each  item. 

5.  OPERATING  STRATEGY 


The  flexibility  of  the  force  movement  option  allows  a  wide  range  of 
scenarios  to  be  generated  quickly.  Sensitivities  to  order  of  march,  move¬ 
ment  priority,  and  weapons  effects  can  be  played  with  minimal  manpower 
expenditure. 

Parent  unit  organization  has  some  limitations.  Only  eight  basic  item 
types  are  allowed.  Some  aggregation  of  support  elements  may  be  required  to 
accommodate  this  limit. 

When  the  numbers  of  basic  item  types  exceed  nine  in  an  organization, 
another  movement  set  must  be  started.  If  more  than  seven  movements  sets 
are  required  by  a  parent  organization  (a  tank  division  at  company  level, 
for  example).  Additional  parent  unit  organizations  may  be  added.  Care 
must  be  taken  to  be  sure  that  the  parent  unit  movement  is  initiated  by  one 
unit  of  each  type. 

The  attack  target  set  options  provide  additional  variety  in  the  analy¬ 
sis  than  can  be  made.  A  wel 1 -structured,  comprehensive  plan  of  sensitivity 
excursions  will  ease  the  analyst's  burden  of  option  selection. 

The  supplemental  reports  used  with  the  restart  options  allow  war  room 
simulations  using  LOGATAK.  The  reports  represent  the  current  network 
status  (at  the  time  of  the  report).  Strikes  against  queues  or  links  could 
be  allocated  (after  an  appropriate  delay)  and  the  run  could  be  restarted 
with  the  new  attacks  included. 

NOTE:  The  new  LOGATAK  data  included  in  the  force  movement  option  is 
contained  in  PDS  (Permanent  Oata  Sets)  storage  and  not  in  PERMAT  as 
described  in  previous  chapters.  Care  must  be  taken  to  include  all  PDS 
service  routines  and  verbs  when  assembling  LOGATAK  for  the  first  time, 
if  the  force  movement  option  is  to  be  used. 
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